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Abstract. The paper describes the refinement algorithm for the Calculus of (Co)Inductive 
Constructions (CIC) implemented in the interactive theorem prover Matita. 

The refinement algorithm is in charge of giving a meaning to the terms, types and 
proof terms directly written by the user or generated by using tactics, decision procedures 
or general automation. The terms are written in an "external syntax" meant to be user 
friendly that allows omission of information, untyped binders and a certain liberal use of 
user defined sub-typing. The refiner modifies the terms to obtain related well typed terms 
in the internal syntax understood by the kernel of the ITP. In particular, it acts as a type 
inference algorithm when all the binders are untyped. 

The proposed algorithm is bi-directional: given a term in external syntax and a type 
expected for the term, it propagates as much typing information as possible towards the 
leaves of the term. Traditional mono-directional algorithms, instead, proceed in a bottom- 
up way by inferring the type of a sub-term and comparing (unifying) it with the type 
expected by its context only at the end. We propose some novel bi-directional rules for 
CIC that are particularly effective. Among the benefits of bi-directionality we have better 
error message reporting and better inference of dependent types. Moreover, thanks to 
bi-directionality, the coercion system for sub-typing is more effective and type inference 
generates simpler unification problems that are more likely to be solved by the inherently 
incomplete higher order unification algorithms implemented. 

Finally we introduce in the external syntax the notion of vector of placeholders that 
enables to omit at once an arbitrary number of arguments. Vectors of placeholders allow 
a trivial implementation of implicit arguments and greatly simplify the implementation of 
primitive and simple tactics. 
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1. Introduction 

In this paper we are interested in describing one of the key ingredients in the implementation 
of Interactive Theorem Provers (ITP) based on type theory. 

The architecture of these tools is usually organized in layers and follows the so called 
de Bruijn principle: the correctness of the whole system solely depends on the innermost 
component called kernel. Nevertheless, from a user perspective, the most interesting layers 
are the external ones, the ones he directly interacts with. Among these, the refiner is the one 
in charge of giving a meaning to the terms and types he writes. The smarter the refiner is, 
the more freedom the user has in omitting pieces of information that can be reconstructed. 
The refiner is also the component generating the majority of error messages the user has to 
understand and react to in order to finish his proof or definition. 

This paper is devoted to the description of a refinement algorithm for the Calculus 
of (Co)Inductive Constructions, the type theory on which the Matita Coq ^12^ and 
Lego [19] ITPs are based on. 

1.1. Refinement. In this and in the previous paper [3] we are interested in the imple- 
mentation of interactive theorem provers (ITP) for dependently typed languages that are 
heavily based on the Curry-Howard isomorphism. Proofs are represented using lambda- 
terms. Proofs in progress are represented using lambda-terms containing metavariables 
that are implicitly existentially quantified. Progression in the proof is represented by in- 
stantiation of metavariables with terms. Metavariables are also useful to represent missing 
or partial information, like untyped lambda-abstractions or instantiation of polymorphic 
functions to omitted type arguments. 

Agda ^ and Matita |6j are examples of systems implemented in this way. Arnaud 
Spiwack in his Ph.D. thesis [31] partially describes a forthcoming release of Coq 8.4 that 
will be implemented on the same principles. 

The software architecture of these systems is usually built in layers. The innermost 
layer is the kernel of the ITP. The main algorithm implemented by the kernel is the type 
checker, which is based in turn on conversion and reduction. The type checker takes as input 
a (proof) term possibly containing metavariables and it verifies if the partial term is correct 
so far. To allow for type-checking, metavariables are associated to sequents, grouping their 
types together with the context (hypotheses) available to inhabit the type. The kernel does 
not alter metavariables since no instantiation takes place during reduction, conversion or 
type checking. 

The kernel has the important role of reducing the trusted code base of the ITP. Indeed, 
the kernel eventually verifies all proofs produced by the outer layers, detecting incorrect 
proofs generated by bugs in those layers. Nevertheless, the user never interacts directly 
with the kernel and the output of the kernel is just a boolean that is never supposed to 
be false when the rest of the system is bug free. The most interesting layers from the user 
point of view are thus the outer layers. The implementation of a kernel for a variant of the 
Calculus of (Co)Inductive Constructions (CIC) has been described in [3] down to the gory 
details that make the implementation efficient. 

The next layer is the refiner and is the topic of this paper. The main algorithm imple- 
mented by the refiner is the refinement algorithm that tries to infer as much information as 
it is needed to make its input meaningful. In other words it takes as input a partial term, 
written in an "external syntax", and tries to obtain a "corresponding" well typed term. 



A BI-DIRECTIONAL REFINEMENT ALGORITHM FOR CIC 



3 



The input term can either be user provided or it can be a partial proof term generated 
by some proof command (cahed tactic) or automation procedure. The gap between the 
external and internal syntax is rather arbitrary and system dependent. Typical examples 
of external syntaxes allow for: 

• Untyped abstractions. Hence the refiner must perform type inference to recover the 
explicit types given to bound variables. The polymorphism of CIC is such that binders 
are required to be typed to make type checking decidable. 

• Omission of arguments, in particular omission of types used to instantiate polymorphic 
functions. Hence the refiner must recover the missing information during type inference 
to turn implicit into explicit polymorphism. 

• Linear placeholders for missing terms that are not supposed to be discovered during type 
inference. For instance, a placeholder may be inserted by a tactic to represent a new 
proof obligation. Hence the refiner must turn the placeholder into a metavariable by 
constraining the set of free variables that may occur in it and the expected type. 

• Implicit ad-hoc sub-typing determined by user provided cast functions (called coercions) 
between types or type families. Hence the refiner must modify the user provided term by 
explicitly inserting the casts in order to let the kernel completely ignore sub-typing. 

Coercions are user provided functions and are thus free to completely ignore their input. 
Thus a refiner that handles coercions is actually able to arbitrarily patch wrong user pro- 
vided terms turning them into arbitrarily different but well typed terms. Moreover, the 
insertion of a coercion between type families can also introduce new metavariables (the 
family indexes) that play the role of proof obligations for pre-conditions of the coercion. 
For instance, a coercion from lists to ordered lists can open a proof obligation that requires 
the list to be sorted. 

The refiner is the most critical system component from the user point of view since it 
is responsible for the "intelligence" of the ITP: the more powerful the refiner is, the less 
information is required from the user and the simpler the outer layers become. For instance, 
a series of recent techniques that really improve the user experience have all been focused 
in the direction of making the refiner component more powerful and extensible by the user. 
Canonical structures [16j, unification hints [5j and type classes [30] are devices that let the 
user drive some form of proof search that is seamlessly integrated in the refinement process. 
While the latter device is directly integrated into the refinement algorithm, the first two 
are found in the unification algorithm used by the refiner. 

They all make it possible to achieve similar objectives, the second being more general 
than the first and the last two being incomparable from the point of view of efficiency 
(where the second is best) and expressiveness (where the third is more fiexible). The 
implementation of type classes done in Coq is actually provided by an additional layer 
outside the refiner for historical reasons. 

In this paper we will describe only the refinement algorithm implemented in a refiner 
for a variant of the Calculus of (Co)Inductive Constructions. The algorithm is used in the 
forthcoming major release of the Matitgj^ ITP (1.0.x). The algorithm calls a unification 
algorithm that will be specified in this paper and described elsewhere. We do not consider 
type classes in our refinement algorithm since we prefer to assume the unification algorithm 
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to implement unification hints. Nevertheless, type classes can be easily added to om' al- 
gorithm with minor modifications and indeed the relevant bits that go into the refiner are 
implemented in Matita. 

Before addressing bi-directionality, which is a peculiarity of the algorithm that has not 
been fully exploited yelj^for the CIC, we just conclude our overview of an ITP architecture 
by talking about the next layer. The next layer after the refiner is that of tactics. This 
layer is responsible for implementing commands that help the user in producing valid proof 
terms by completely hiding to him the proof terms themselves. Tactics range from simple 
ones that capture the introduction and elimination rules of the connectives (called primitive 
tactics) to complicated proof automation procedures. The complexity of proof automation 
is inherent in the problem. On the other hand, primitive tactics should be as simple as 
building small partial proof terms. For instance, to reduce a proof of A ^ B to a proof of 
B given A it is sufficient to instantiate the metavariable associated to the sequent \- A ^ B 
with the term \x.? in external syntax where ? is a placeholder for a new proof obligation. 
This is possible when the refinement algorithm is powerful enough to refine Xx.7 to Xx : A.fi 
where ?i is a new metavariable associated to the sequent x : Ah B. When this is not the 
case or when the refiner component is totally missing, the tactic is forced to first perform 
an analysis of the current goal, then explicitly create a new metavariable and its sequent, 
and then emit the new proof term Xx : A.7i directly in the internal syntax. 

1.2. Bi-directionality. When the external syntax of our ITP allows to omit types in 
binders, the refinement algorithm must perform type inference. Type inference was origi- 
nally studied in the context of lambda-calculi typed a la Curry, where no type information 
can be attached at all to the binders. The traditional algorithm for type inference, now 
called uni-directional, performs type inference by first traversing the term in a top-down 
way. When a binder is met, a new metavariable (usually called type or unification variable 
in this context) is introduced for the type of the bound variable. Then type constraints are 
solved traversing the term in a bottom-up way. When the variable or, more generally, a 
term is used in a given context, its type (called inferred type) is constrained to be compati- 
ble with the one expected by the context (called expected type). This triggers a unification 
problem. 

Type inference, especially for the Hindley-Milner type system, gives the possibility 
to write extremely concise programs by omitting all types. Moreover, it often detects a 
higher degree of polymorphism than the one expected by the user. Unluckily, it has some 
drawbacks. A minor one is that types are useful for program documentation and thus the 
user desires to add types at least to top level functions. In practice, this is always allowed 
by concrete implementations. Another problem is error reporting: a typing error always 
manifests itself as a mismatch between an inferred and an expected type. Nevertheless, an 
error can be propagated to a very distant point in the code before being detected and the 
position where it is produced. The mismatch itself can be non informative about where 
the error actually is. Finally, unification quickly becomes undecidable when the expressive 
power of the type system increases. In particular, it is undecidable for higher order logic 
and for dependent types. 

^The refinement algorithm of Coq 8.3, the most widespread implementation of CIC, is almost mono- 
directional with only the lambda-abstraction case handled in a bi-directional way. Many other interesting 
cases of bi-directionality are obtained in this paper for inductive types and constructors. 
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To avoid or mitigate the drawbacks of type inference, bi-directional type-checking algo- 
rithms have been introduced in the literature j24j . These algorithms take as input a A-term 
typed a la Curry and an expected top-level type and they proceed in a top-down manner 
by propagating the expected type towards the leaves of the term. Additional expected 
types are given in local definitions, so that all functions are explicitly documented. Error 
detection is improved by making it more local. The need for unification is reduced and, 
for simple type systems, unification is totally avoided. Some terms, in particular /3-redexes, 
are no longer accepted, but equivalent terms are (e.g. by using a local definition for the 
head). An alternative consists of accepting all terms by re- introducing a dependency over 
some form of unification. 

Bi-directionality also makes sense for languages typed a la Church, like the one we 
consider here. In this case the motivations are slightly different. First of all, typing infor- 
mation is provided both in the binders and at the top-level, in the form of an expected type. 
Hence information can flow in both direction and, sooner or later, the need to compare the 
expected and inferred types arises. In the presence of implicit polymorphism, unification 
is thus unavoidable. Because of dependent types and metavariables for proof obligations, 
we need the full power of higher order unification. Moreover, again because of unification, 
the problem remains undecidable also via using a bi-directional algorithm. Hence avoiding 
unification is no longer a motivation for bi-directionality. The remaining motivations for 
designing a bi-directional refinement algorithm for CIC are the following: 

Improved error messages. A typing error is issued every time a mismatch is found between 
the inferred and expected type. With a mono-directional algorithm, the mismatch is always 
found at the end, when the typing information reaches the expected type. In a bi-directional 
setting the expected type is propagated towards the leaves and the inferred type towards 
the root, the mismatch is localized in smaller sub-terms and the error message is simpler. 
For instance, instead of the message "i/ie provided function has type A ^ List B hut it is 
supposed to have type A =^ List C" related to a whole function definition one could get the 
simpler message "i/ie list element has type B hut it is supposed to have type C" related to 
one particular position in the function body. 

Improvement of the unification algorithm. To make the system responsive, the semi-decidable 
unification algorithm is restricted to always give an answer in a finite amount of time. Hence 
the algorithm could fail to find a solution even when a solution exists. For instance, the 
algorithms implemented in Coq and Matita are essentially backtracking free and they sys- 
tematically favor projections over mimics: when unifying an applied metavariable ?i a 6 c 
with a h (for some a, 6, c closed in a context P), the system instantiates ?i with Xx,y,z.y 
rather than Xx,y,z.b (where x,y,z ^ dom{T)). Moreover, unification for CIC does not 
admit a most general unifier and it should recursively enumerate the set of solutions. How- 
ever, it is usual in system implementations to let unification return just one solution and 
to avoid back-tracking in the refinement algorithnij^ Thus, if the solution found by unifi- 
cation is correct locally, but not globally, refinement will fail. Thanks to bi-directionality, 
unification problems often become more instantiated and thus simpler, and they also admit 
fewer solutions. In particular, in the presence of dependent types, it is easy to find practical 
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examples where the unification algorithm finds a solution only on the problems triggered 
by the bi-directional algorithm. 

An interesting and practical example that motivated our investigation of bi-directionality 
is the following. Consider a dependently typed data-type (Term S) that represents the 
syntax of a programming language with binders. Type dependency is exploited to make 
explicit the set S of variables bound in the term and every variable occurrence must 
come with a proof that the variable occurs in the bound variables list: (Var S x 1) 
has type (Term S) where x is a variable name, I is a proof of True and Var has type 
VS.Va : String. X G 5" — )• Term S where x G S" is a computable function that reduces to True 
when X belongs to S and to False otherwise. Consider now the term (Lambda ? x (Var ? x I)) 
in concrete syntax that represents Xx.x in our programming language. Note that no infor- 
mation about the set of bound variables has been provided by the user. Thus it is possible to 
simply define notational macros so that the user actually writes Xx.x and this is expandecQ 
to Lambda ? x (Var ? x I). A uni-directional refiner is unlikely to accept the given term 
since it should guess the right value for the second placeholder ? such that x G ? reduces 
to True and ? is the set of variables actually bound in the term. The latter information is 
not local and it is still unknown in the bottom-up, uni-directional approach. On the other 
hand, a bi-directional refiner that tries to assign type Term to the term would simply 
propagate to the first placeholder and then propagate U {x} to the second one, since 
Lambda, which is a binder, has type V5.Vx.Term (SU {x}) — )• Term S. Finally, True is the 
inferred type for I, whose expected type is x G U {x}. The two types are convertible and 
the input is now accepted without any guessing. 

Improvement of the coercion mechanism. Coercions are triggered when unification fails. 
They are explicit cast functions, declared by the user, used to fix the type of sub-terms. 
Simplifying the unification problem allows to retrieve more coercions. For instance, consider 
a list [1; 2; 3] of natural numbers used as a list of integer numbers and assume the existence of 
a coercion function k from natural to integers. In the mono-directional problem, the failing 
unification problem is (List N) vs (List Z). The coercion required is the one obtained lifting 
k over lists. The lifting has to be performed manually by the user or by the system. In the 
latter case, the system needs to recognize that lists are containers and has to have code to 
lift coercions over containers, like in |10j . In the bi-directional case, however, the expected 
type (List Z) would propagate to assign to each list element the expected type Z and the 
coercion k would be applied to all integers in the list without need of additional machinery. 
The bi-directional algorithm presented in this paper does not allow to remove the need for 
the coercion over lists in all situations, but it is sufficient in many practical ones, like the 
one just considered. 

Introduction of vectors of placeholders (". . . ") in the external syntax. A very common use 
of dependently typed functions consists in explicitly passing to them an argument which is 
not the first one and have the system infer the previous arguments using type dependencies. 
For instance, if Cons : WA.A — )• List A — )• List A and / is a list of integers, the user can 
simply write (Cons 7 2 1) and have the system infer that ? must be instantiated with the 
type of 2, which is N. 



User provided notational macros are used to extend the external syntax of an ITP and they are expanded 
before refinement, yielding a term in external syntax to be refined. 
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This scenario is so common that many ITPs ahow to mark some function arguments 
as impUcit arguments and let the user systematically avoid passing them. This requires 
additional machinery implemented in the ITP and it has the unfortunate drawback that 
sometimes the user needs to explicitly pass the implicit arguments anyway, in particular in 
case of partial function applications. This special situation requires further ad-hoc syntax to 
turn the implicit argument into an explicit one. For instance, if we declare the first argument 
of Cons implicit, then the user can simply write (Cons 2 I) for the term presented above, 
but has to write something like (@Cons N), in Coq syntax, to pass the partial function 
application to some higher order function expecting an argument of type N — )• List N — )• 
List N. 

An alternative to implicit arguments is to let the user explicitly insert the correct 
number of placeholders "?" to be inferred by the system. Series of placeholders are neither 
aesthetic nor robust to changes in the type of the function. 

A similar case occurs during the implementation of tactics. Given a lemma L : Hi — )• 
...—)• Hn — )• C, to apply it the tactic opens n new proof obligations by refining the term 
(L ? . . . ?) where the number of inserted placeholders must be exactly n. 

In this paper we propose a new construct to be added to the external syntax of ITPs: 

— > 

a vector of placeholders to be denoted by ? and to be used in argument position only. In 

— > 

the actual external syntax of Matita we use the evocative symbol ". . . " in place of ? . The 

— > — & 

semantics associated to ? is lazy: an ? will be expanded to the sequence of placeholders of 
minimal length that makes the application refineable, so that its inferred type matches its 
expected type. In a uni-directional setting no expected type is known in advance and the 
implementation of the lazy semantics would require computationally expensive non-local 
backtracking, which is not necessary in the bi-directional case. 

Thanks to vectors of placeholders the analysis phase of many primitive tactics imple- 
mentation that was aimed at producing terms with the correct number of placeholders can 
now be totally omitted. Moreover, according to our experience, vectors of placeholders 
enable to avoid the implementation of implicit arguments: it is sufficient for the user to 

— o 

insert manually or by means of a notation a ? before the arguments explicitly passed, with 

— > 

the benefit that the ? automatically adapts to the case of partial function application. For 

— > 

example, using the infix notation :: for (Cons ?), the user can both write 2 :: /, which 

—t> 

is expanded to (Cons ? 2 1) and refined to (Cons N 2 and pass :: to an higher order 
function expecting an argument of type N — )• List N — )• List N. In the latter case, :: is 

— o 

expanded to (Cons ?) that is refined to (Cons N) because of the expected type. If :: is 
passed instead to a function expecting an argument of type \/A.A — )■ List A — t- List A, then 

(Cons ? ) will be expanded simply to Cons whose inferred type is already the expected one. 

The rest of the paper explains the bi-directional refinement algorithm implemented in 
Matita [6]. The algorithm is presented in a declarative programming style by means of 
deduction rules. Many of the rules are syntax directed and thus mutually exclusive. The 
implementation given for Matita in the functional OCaml language takes advantage of the 
latter observation to speed up the algorithm. We will clarify in the text what rules are 
mutually exclusive and what rules are to be tried in sequence in case of failure. 
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The refinement algorithm is presented progressively and in a modular way. In Section [3] 
we introduce the mono-directional type inference algorithm for CIC implemented following 
the kernel type checker code (that coincides with type inference if the term is ground) of 
Matita. The presentation is already adapted to be extended in Section |4] to bi-directional 
refinement. In these two sections the external and internal syntaxes coincides. In Section [5] 
we augment the external syntax with placeholders and vectors of placeholders. Finally, in 
Section [6] we add support for coercions. In all sections we will prove the correctness of the 
refinement algorithms by showing that a term in external syntax accepted by the refiner 
is turned into a new term that is accepted by the kernel and that has the expected type. 
Moreover, a precise correspondence is established between the input and output term to 
grant that the refined term corresponds to the input one. 

For the sake of the reader, Appendix [s] is taken from [3] with minor modifications and 
it shows the type checking algorithm implemented by the kernel. The syntax of the calculus 
and some preliminary notions are also introduced in Section [2] before starting the description 
of the refinement algorithm. 

2. Preliminaries 

2.1. Syntax. We begin introducing the syntax for CIC terms and objects in Table [T] and 
some naming conventions. 

To denote constants we shall use c, ci, C2 . . . ; the special case of (co) recursively defined 
constants will be also denoted using /, /i,/2 we reserve x,y,xi,X2 ...for variables; 
t, u, V, t' , t" , ti,t2 ... for terms; T, U, V, E, L, R, T' , T" , Ti, T2 ... for types and we use s, s' , si 
. . . for sorts. 

We denote by F a context made of variables declarations (x : T) or typed definitions 
{x := t : T). We denote the capture avoiding substitution of a variable x for a term t by 
[x/t\. The notation [xi/ii; . . . ; x^/tn] is for simultaneous parallel substitution. 

To refer to possibly empty) sequences of entities of the same nature, we use an arrow 
notation (e.g. t ). For the sake of conciseness, it is sometimes convenient to make the 
length of a sequence explicit, while still referring to it with a single name: we write tn to 
mean that tn is a sequence of exactly n elements and, in particular, that it is a shorthand 
for t,t,... t„; the index n must be a natural number (therefore the notation^ referstoa 

non-empty sequence). The arrow notation is extended to telescopes as in (x : t) or (x„ : tn) 
and used in binders, (co)recursive definitions and pattern matching branches. 

As usual, IIx : T1.T2 is abbreviated to Ti — )• T2 when x is not a free variable in T2. 
Applications are n-ary, consisting of a term applied to a non-empty sequence of terms. 

Inductive types Ii are annotated with the number / of arguments that are homogeneous 
in the types of all constructors. For example consider the inductive type of vectors Vect 
of arity HA : Type.N — >• Type. It takes two arguments, a type and a natural number 
representing the length of the vector. In the types of the two constructors, Vnil : Vect A 
and Vcons : Ilm, Vect A m ^ A ^ Vect A [m + 1), every occurrence of Vect is applied 
to the same argument A, that is also implicitly abstracted in the types of the constructors. 
Thus Vect has one homogeneous argument, and will be represented by the object 

HA : Type, inductive Vect : N Type := 

Vnil : Vect A | Vcons : Ilm, A Vect Am^ Vect A {m + 1) 
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X 
C 
II 

k 

Prop I Type„ 
\x : t.t 

let {x : t) := t in t 
Ux : t.t 



match t in Ii return t [ki (x : t) ^ t 
... ; t] 



kn (x : t) t] 



identifiers 
constants 
inductive types 
inductive constructors 
sorts 

n-ary application 
A-abstraction 
local definitions 
dependent product 

case analysis 
metavariable occurrence 



let rec fi {x : t) : t := t and . . . and (x : t) : t := t 



and fn {x : t) : t := t 



let corec /i {x : t) : t := t and 
definition c : t :=t 
axiom c : t 

ILxi : ti- inductive : A := ki^i : t \ ... | ki^rm 
with . . . 

with ip : A := kn,i : t \ ... \ kn,mn ■ * 



: t 



recursive definitions 

co-recursive definitions 

definitions 

axioms 

inductives 



Table 1: CIC terms and objects syntax 



and referred to with Vecti. This is relevant for the pattern matching construction, since the 
homogeneous arguments are not bound in the patterns because they are inferred from the 
type of the matched term. For example, to pattern match over a vector v of type (Vect N 3) 
the user writes 

match V in Vecti return T [Vnil ^ ti \ Vcons (m : N) (re : N) (v' : Vect N m) =^ ^2] 

The inductive type // in the pattern matching constructor is (almost) redundant, since 
distinct inductive types have distinct constructors; it is given for the sake of readability and 
to distinguish the inductive types with no constructors. In a concrete implementation it 
also allows to totally drop the names of the constructors by fixing an order over them: the 
i-th pattern will be performed on the z-th constructor of the Ii inductive type. 

Since inductive types may have non homogeneous arguments, not every branch is re- 
quired to have exactly the same type. The term introduced with the return keyword is a 
function that computes the type expected by a particular branch and also the type of the 
entire pattern matching. Variables {x : t] are abstracted in the right hand side terms of 

The definitions of constants c (including (co)recursive constants /), inductive types Ii 
and constructors k are collected in the syntactic category of CIC objects o. 

Metavariable occurrences, represented with ; ... ; tn], are missing typed terms 
equipped with an explicit local substitution. The index j enables metavariables to occur 
non-linearly in the term. To give an intuition of the role played by the local substitution, 
the reader C3-n think of j • • • ? ] as a call to the, still unknown, function ?j with 
actual arguments ti . . . The terms ti . . .tn will be substituted for the formal arguments 
of the ?j function inside its body only when it will be known. 
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We omit to write the local substitution when it is the identity substitution that sends 
all variables in the current context with themselves. Thus ?j will be a shorthand for 
; ... ; Xn] when the variables bound in the right order in the con- 

text of the metavariable occurrence. 

The CIC calculus extended with metavariables has been studied in [21] and the flavor 
of metavariables implemented in Matita is described in |26j . 

2.2. Typing rules. The kernel of Matita is able to handle the whole syntax presented 
in the previous section, metavariables included. While we report in the Appendix [8] the 
full set of typing rules implemented by the kernel, here we summarise only the ones that 
will be reused by the refinement algorithm. We will give a less formal but more intuitive 
presentation of these rules, defining them with a more concise syntax. Moreover, we will 
put our definition in linear order, while most of them are actually mutually recursive. 

Definition 2.1 (Proof problem (S)). A proof problem S is a finite list of typing declarations 
of the form F?. h?, : T? .. 

A proof problem, as well as a CIC term, can refer to constants, that usually live in 
an environment that decorates every typing rule (as in the Appendix |8]) . In the following 
presentation we consider a global well formed environment Env, basically a collections of 
CIC objects defining all constants and inductive types and associating them to their re- 
spective types. No refinement rule will modify this environment that plays no role in this 
presentation. In fact it is the task of the kernel to enable well typed definitions, inductive 
types and (co-) recursive functions to enter the environment. 

We thus omit the environment Env from the input of every judgment. We will fetch 
from it the type T of a constant, inductive type or constructor r writing (r : T) S Env. 

We regard CIC as a Pure Type System 0, and we denote by PTS the set of axioms. We 
denote by s S PTS any sort of the PTS, with (si : S2) £ PTS the fact that S2 types si, and 
with (si,S2)'53) S PTS the fact that a product over si to S2 has sort S3. CIC is a full but 
not functional PTS: all products are well formed but in (si, S2, S3) G PTS it may be S2 7^ Ss- 
This is because the calculus is parameterized over a predicative hierarchy Type„ for u in a 
given set of universe indexes. In a predicative setting, given si = Type^^ and S2 = Type^^; 
S3 is defined as Type^ax{ui,n2} according to some bounded partial order on the universe 
indexes. The details for the actual PTS used in Matita are given in [3]. We will often write 
simply Type when we are not interested in the universe index (e.g. in examples). We also 
write Typey for the biggest sort in the hierarchy, if any, or a variable universe to be later 
fixed to be big enough to satisfy all the required constraints. 

We also write (si,S2) G elim(PTS) to check if an element of an inductive type of sort 
si can be eliminated to inhabit a type whose sort is S2. This is relevant for CIC since the 
sort of propositions. Prop, is non informative and cannot be eliminated to inhabit a data 
type of sort Type„ for any u (but for few exceptions described in [4J Section 6). 

Proof problems do not only declare missing proofs (i.e. not all T-?. have sort Prop) but 
also missing terms and, of particular interest for this paper, missing types. 

Definition 2.2 (Metavariable substitution environment {^)). A metavariable substitution 
environment <I> (called simply substitution when not ambiguous) is a list of judgments of 
the form 

Pv, h?,- := t7. : Tv^ 
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stating that the term t?_. of type T?^ in F?^. has been assigned to ?j. 

We now anticipate the typing judgment of the kernel. A formal definition of well 
formedness for S and ^ will follow. 

Definition 2.3 (Typing judgment). Given a term t, a proof problem S and a substitution 
<I>, all assumed to be well formed, we write 

S, Tht:T 

to state that t is well typed of type T. 

When S, <I>, T h t : T the type T is well typed and its type is either a metavariable or 
a sort s G PTS. 

The typing judgment implemented in our kernel is an extension of the regular typing 
judgment for CIC [35l [231 [13] . It is described in fl] and reported in the Appendix [sj Here 
we recall the main differences: 

• Substitution of a regular variable x for a term t is extended with the following rule for 
metavariables: 

?j[ti ; ... ; tn][x/t] =?j[ti[x/t] ; ... ; tn[x/t]] 

• The conversion relation (denoted by \.) is enlarged allowing reduction to be performed 
inside explicit substitution for metavariables: 

Thtiit'i ie{l...n} 

rh7,[h; ... ; t.] i7j[t[; . . . ; t'J 

• The following typing rules for metavariables are added: 

yi ■ Ti ; . . . ; yn ■■ Tn : T?^ G S 

T\- U: Ti[yi/ti ; . . . ; Vi-i/U-i] i £ {l...n} 

rhWH?,[h ; ... ; in]) 
{yi-.Ti; ... ; Vn-.Tn h?,- : TvJ £ S T h WT{7j[h ] ■ ■ ■ ] tn]) 
r h?j[ii ; ... ; tn\: T7.\yi/ti ; . . . ; yn/tn] 
Moreover, in many situations a metavariable occurrence is also accepted as a valid sort, 
marking it so that it cannot be instantiated with anything different from a sort. This 
additional labelling will be omitted, being marginal for the refinement algorithm. 

The technical judgment T h WJ-"(?j[ti ; ... ; tn]) states that a metavariable occurrence 
; ... ; tn] is well formed in F. 
In all the previous rules we assumed access to a global well formed proof problem S 
and substitution $. Both E and $ are never modified by the judgments implemented in 
the kernel. 

We now present the well formedness conditions, corresponding to the judgments h WF 
presented in the Appendix [8| 

Definition 2.4 (Metavariables of term/context {M))- Given a term t, M.{t) is the set of 
metavariables occurring in t. Given a context F, A^(F) is the set of metavariables occurring 
in F. 

The function A4. is at the base of the order relation defined between metavariables. 

Definition 2.5 (Metavariables order relation (^e ))• Let S be a proof problem. Let <s 
be the relation defined as: ?ni <2 ?re2 iff ??t-i G A^(F7n2) U A^(T?„2). Let be the 

transitive closure of <x; . 
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Definition 2.6 (Valid proof problem). A proof problem S is a valid proof problem if and 
only if is a strict partial order (or, equivalently, if and only if is an irreflexive 
relation). 

The intuition behind <Cs is that the smallest ?j (or one of them since there may be more 
than one) does not depend on any other metavariable (e.g. A^(r7 ,) = and A^(T? .) = 
where T-?. : T?. G S). Thus instantiating every minimal ?j with a metavariable free term 
will give a new S in which there is at least one ?j not depending on any other metavariable 
(or S is empty). This definition is the key to avoid circularity in the following definitions. 

In the rules given in Appendix [S] the partial order is left implicit by presenting S as 
an ordered list. However, as proved by Strecker in his Ph.D. thesis [M], the order is not 
preserved by unification and thus in any realistic implementation S is to be implemented 
as a set and the fact that remains a partial order must be preserved as an invariant. 

Definition 2.7 (Well formed context (WJ-"(r))). Given a well formed proof problem S, a 
context r = yi : Ti, . . . , y„ : T„ is well formed (denoted by WJ^{T)) if A^(r) C S and for 
every i 

yi -Ti,. . . : Ti_i \- yi : Ti 

Definition 2.8 (Well formed proof problem (WJ^(S))). A valid proof problem S is a well- 
formed proof problem (denoted by WJ^(S)) if an only if for all (F?, : T? .) £ T, we have 
S,r7 . h Tv . : s and s G PTS. 

Definition 2.9 (Well formed substitution (VVJ^(<I'))). Given a well formed proof problem 
E, a substitution <I> is well formed (denoted by >VJ"($)) if for every (T?^^ := ti. : T?^.) e $ 
we have S, 0, F? . h t? , : T? . . 

The well formedness definitions given so far are actually implemented by the kernel in 
a more precise but less intuitive way. We thus refer to the kernel judgments in the following 
definition, that will be used in the specification of all refinement rules. 

Definition 2.10 (Well formed status (WJ^(S, F))). Given a proof problem S, a sub- 
stitution <I> and a context F, the triple S, F is well formed (denoted by WJ^(S, F)) 
when WJ'(S) and WJ"($) and >VJ"(F). 

We shall sometimes omit F, considering it equal to a default, well formed context, like 
the empty one. The recursive operation of applying a substitution $ to a term t is denoted 
by $(t) and acts as the identity for any term but metavariables contained in on which 
it behaves as follows: 

^>(?j[ti ; . . . ; t„]) = ti. [yi/ti ; . . . ; yn/tn] when (yi : Ti; . . . ; y„ : r„ := ti. : T?^ G $ 

Note that, thanks to the extensions to the type checking rules made in Definition |2.3[ 
substitution application is type preserving. Substitutions do apply also to well formed 
proof problems in the following way: 

«>(Fv^. h?, : Tv^,) = $(F7^,) h?,- : ^(rv^,) (for each ?j G S) 

The substitution application operation is seldom used explicitly, since all judgments 
take as input and give back a substitution. Nevertheless it will be used in the examples. 

Definition 2.11 (Weak-head normalization (i>whd))' Given a context F, substitution <I> and 
proof problem S, all assumed to be well formed, it computes the weak head normal form 
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of a well typed term t according to the reduction rules of CIC. It is denoted by: 

Note that ?j is in weak head normal form iff ?j 

By abuse of notation we will write S, <I>, F h ti l>whd IIxi : Ti . . .Hxn ■ Tn-tn+i to 
mean that for alH G {1 . . . n} S, F; xi : Ti; . . . ; Xi^i : Tj-i h ti l>whd Ilxj : Ti.ti+i and 
S, r h tn+i >whd tn+i- Such repeated use of weak head computation to produce spines 
of dependent products occur frequently in the kernel and in the refinement rules, especially 
when dealing with inductive types. 

Definition 2.12 (Conversion (i)). Given a proof problem S, substitution <I> and context 
r, all assumed to be well formed, and two terms ti and t2, it verifies if ti and t2 have a 
common normal form according to the rules of CIC given in Appendix [Sj It is denoted by: 

s, rhtiit2 

3. MONO-DIRECTIONAL REFINEMENT 

We now present the mono-directional refinement algorithm for CIC implemented in the old 
versions of Matita (0.5.x) and directly inspired by the rules for type checking implemented 
in the kernel. In this section we assume the external syntax to coincide with the syntax of 
terms. Hence the algorithm actually performs just type inference. Nevertheless, we already 
organize the judgments in such a way that the latter extension to bi-directionality will be 
achieved just by adding new typing rules. 

3.1. Specification. To specify what is a refinement algorithm we must first introduce the 
notion of proof problem refinement. Intuitively, a pair (proof problem, substitution) is 
refined by another pair when the second is obtained by reducing some proof obligations to 
new ones. It thus represents an advancement in the proof discovery process. 

Definition 3.1 (Proof problem refinement (<)). We say that refines S,<I> (denoted 

by S', < S, ^>) when ^> C and for every (r?^ h?^ : T?^) G S either (r',. h?j : ) e H' 

or (r,>?,- := t?. : T,',) G where r', = ^>'(r7 .) and = ^>'(T7 ,). 

Specification 3.2 (Refiner in type inference mode (7^^)). A refiner algorithm TZ in type 
inference mode ft takes as input a proof problem, substitution and context, all assumed 
to be well formed, and a term t. It fails or gives in output a new proof problem, a new 
substitution, a term t' and a type T' . It is denoted by: 

(s, $) r h t ^ t' : r (S', $') 

Precondition: 

W-F(E, r) 

Postcondition (parametric in ^): 

>VJ"(S', ^>') A S',$'<S,$ A S', r h t' : T' A t' 4 t 

The specification is parametric in the ^ relation that establishes a correspondence 
between the term t to be refined and the refiner output t' . In order to prove correctness, 
we are only interested in admissible ^ relations defined as follows. 
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Definition 3.3 (Admissible relations (^)). A partial order relation ^ is admissible when 
for every term ti in external syntax and t2 and T in internal syntax and for every variable 
X occurring free only linearly in T we have that ti ^ t2 implies T[j;/ti] =^ T[x/t2]. 

Admissibility for equivalence relations correspond to asking the equivalence relation to 
be a congruence. 

When the external syntax corresponds to the term syntax and coercions are not con- 
sidered, we can provide an implementation that satisfies the specification by picking the 
identity for the ^ relation. Combined with E',$' < T,,^, the two postconditions imply 
that ^{t') must be obtained from t simply by instantiating some metavariables. In Sec- 
tions [5] and [6j we shall use weaker definitions of ^ than the identity, allowing replacement 
of (vectors of) placeholders with (vectors of) terms and the insertion of coercions as results 
of the refinement process. All the ^ relations considered in the paper will be large partial 
orders over terms of the external syntax (that always include the internal syntax). 

We will now proceed in presenting an implementation of a refinement algorithm in type 

inference mode -w. The implementation is directly inspired by the type checking rules 
used in the kernel. However, since refinement deals with terms containing flexible parts, 
conversion tests need to be replaced with unification tests. In a higher order and dependently 
typed calculus like CIC, unification is in the general case undecidable. What is usually 
implemented in interactive theorem provers is an essentially fist order unification algorithm, 
handling only some simple higher order cases. The unification algorithm implemented in 
Matita goes beyond the scope of this paper, the interested reader can find more details 
in \26\ [5]. Here we just specify the expected behavior of the unification algorithm. 

7 

Specification 3.4 (Unification (= — U)). An unification algorithm takes as input a proof 
problem, a substitution and a context, all assumed to be well formed, and two well typed 
terms ti and t2- It fails or gives in output a new proof problem and substitution. It is 
denoted using the following notation where • can either be = or be omitted. In the former 
case universe cumulativity (a form of sub-typing) is not taken in account by unification. 

(s, $) r h ti = t2 ^ (s', ^>') 

Precondition: 

W-F(s, r) A s, r h ii : Ti A s, r h t2 : T2 

Postcondition: 

WF{T.\ $') A s', < s, $ A s', r h t; u t'2 



3.2. Implementation. 

3.2.1. Additional judgments. For the sake of clarity we prefer to keep the same structure 
for the mono and bi-directional refiners. We thus give the definition of some functions that 
are trivial in the mono-directional case, but will be replaced by more complex ones in the 
following sections. 

Even if we presented the syntax of CIC using the same category terms, types and sorts, 
some primitive constructors (like the A and H abstractions) expect some arguments to be 
types or sorts, and not terms. A type level enforcing algorithm forces a term in external 
syntax to be refined to a valid type. 
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Specification 3.5 (Type level enforcing {J-)). A type level enforcing algorithm takes as 
input a proof problem S, a substitution $ and a context F, all assumed to be well formed, 
and a term T. It fails or it returns a new term T' , a sort s, a new substitution <!>' and proof 
problem S'. It is denoted by: 

(S, $) r h T ^ T' : s (S', 

Precondition: 

r) 

Postcondition (parametric in ^): 

WT{^', <^') A S',$'<S,$ A S', rhT':s A s G PTS A T' =^ T 

Note that one may want to accept a metavariable as the sort s, eventually labelling it in 
such a way that the unification algorithm will refuse to instantiate it with a different term. 
The choice must be consistent with the one taken in the implementation of the kernel. 

The task of checking if a term has the right type is called refinement in type forcing mode 

and it will be denoted by -w. In the mono-directional case, will be simply implemented 

calling the ^ algorithm that will handle coercions in Section [g] but which, at the moment, 
only verifies that no coercion is needed by calling the unification procedure. 

Specification 3.6 (Explicit cast (C)). A cast algorithm takes as input a proof problem 
S, a substitution <I> and a context P, all assumed to be well formed, and a term t with its 
inferred type T and expected type T' . It fails or it returns a new term t' of type T', a new 
proof problem E' and substitution It is denoted by: 

(S, $) P h t : T = T' ^ t' (S', 

Precondition: 

WJ"(S, P) A S, P h t : T A S, P h T' : s 
Postcondition (parametric in =^): 

WF{T.', A S', A S', P h t' : T' A t' ^ t 

Specification 3.7 (Refiner in type forcing mode (7^''^)). A refiner algorithm TZ in type 
forcing mode JJ- takes as input a proof problem S, a substitution $ and a context P, all as- 
sumed to be well formed, and a term t together with its expected well formed type T. It fails 
or returns a term t' of type T, a new proof problem S' and substitution It is denoted by: 

(S, $) P h i : T U t' (S', ^>') 

Precondition: 

W-F(S, P) A S, P h T : s 
Postcondition (parametric in =<;): 

W-F(S', ^>') A S', < S, $ A S', P H t' : T A t' 4 t 
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3.2.2. Notational conventions. The arguments S and ^ will be taken as input and returned 
as output in all rules that define the refiner algorithm. To increase legibility we adopt the 
following notation, letting S and $ be implicit. Each rule of the form 

^ Tht' ^ t" 
(rule) — — — 



has to be interpreted as: 

(E, $) r h t -w t' 
(S', r h t' ^ t" (S", 



{rule) 



Moreover we will apply this convention also to rules not returning E or $ as if they were 
returning the E or <I> taken as input. 

Note that the E' and returned by all rules considered in this paper are well formed 
and are also a proof problem refinement of the E and <I> provided as input. Being a proof 
problem refinement is clearly a transitive relation. Thus we have for free that all the omitted 
pairs (proof problem, substitution) are refinements of the initial ones. 



3.2.3. Role of the relations and their interaction. In this paragraph we shortly present the 
role played by the relations and introduced so far and the auxiliary ones 

^ and that will be specified when needed. 

The relation links a term with its inferred type, while links a term with the 

type expected by its context. will thus exploit the extra piece of information not only 

checking that the inferred type unifies with the expected one, but also propagating this 

fit 

information to its recursive calls on subterms (when possible), and will be defined 
in a mutually recursive way. 

The relation ^ links a term with its refinement asserting that the refinement is a 
type. This is relevant when typing binders like (Ax : t.t'), where t is required to be a type. 
In its simplest formulation the relation is a simple assertion, linking a type with itself. In 
Section [6] the refinement relation ^ will admit to link a term t that is not a type with 
a function applied to t that turns its input into a type. For example t may be a record 
containing a type and ^ may link it with (7r„ t), where vr^ is the projection extracting 

jr fit 

the type from the record, is recursively defined in terms of 



The relation links a term i, its inferred type Ti and the type expected by its context 
T2 with a refinement of the term t' asserting that the refined term has type T2 . In its simple 
formulation the relation is a simple assertion that Ti and T2 are the same and thus links 
t with itself. In Section [6] the refinement relation ^ will admit to explicitly cast t. For 
example a natural number n of type N may be casted into the rationals Q refining it to 

{\x : N.x/1) n. The relation is non recursive. 
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The relations and are auxiliary relations only used to ease the presentation 
of the and relations in the case of applications. Both auxiliary relations are thus 

Tit -Ji^ 

recursively defined with and 

3.2.4. Rules for terms. We now give an implementation for the refiner in both modes and 
for the auxiliary judgments. The implementation is parametric on the unification algorithm, 
that is not described in this paper. 

r h f ^ t' : T' 

r ^ ThTi = T2 ^ ^7^4 ^ T h t' :T' = T t" 

( —ok) ( —default) 



Tht:Ti=T2 ^ t Tht: T^^ t" 

r h T ^ T' : s si G PTS 

, T , r h T' : s = si £^ T" 
( -w —ok) 



ThT ^ T" : s 

Note that si is arbitrary, and the actual code prefers the predicative sorts Type„ over 
Prop. This is the only rule defined in this section to be non syntax oriented: in case of 
an incorrect choice of si, backtracking is required. The actual algorithm implemented in 
Matita performs the choice of si lazily to remain backtracking free 



ni^ {x:T)€r or (x := t : T) G T 
( ^ -variable) 

T \- X X : T 



TZt (r:r)GEnv r£{k,I,c} 
[ -constant) 

r h r r : T 

(si:s2)gPTS 
(--sort) — 

i h si si : S2 
(rv>V^)GS or (r?^ h?, := t,^. : TvJ G <f 

r?, — Xfi . 

> v'i- 

^ , Thti-. Ti[xi„i/t^„i] ^ iG{l...n} 
( -meta) ^— ^ =^ 

Note that the operation of firing a /3-redex must commute with the operation of applying 
a substitution <I>. Consider for example the term v = (Ax.?j[x]) u and the substitution 
^ = {x : T := t{x) : T{x)}. If one applies the substitution first, and then reduces 
the redex obtains t(u), whose type is T{u). If one fires the redex fist, the fact that x is 
substituted by u in Ij is recorded in the local substitution attached to the metavariable 

'^Laziness will be no longer sufficient to avoid backtracking when we will add additional rules to handle 
coercions in Section jo] 
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instance. Indeed 0,0,0 h w i>whd?jM and <^>(?j[ii]) = t{u) : T{u). Therefore '!j[u] is given 

7^ ti- 
the type T(u) by the rule ( — meta). 

ThT ^ T' : s 

r h t : T' U t' 

Tit r;x:=t':T'\-u-^u':T2 
( -letm) --^ 

r h let (x ■.T):=tinu ^ let (x : T') := t' in u' : T2[x/t'^] 

r h Ti ^ r{ : si 

( ^ -lambda) — 

r h Ax : Ti.t ^ Xx : T{.t' : Hx : T{.T 

r h Ti ^ T[: si 

T;x:T{hT2 ^ : 
,7e* , {si, 82,83) £ PTS 



-product) 



r h nx : T1.T2 ^ Ux : T[.T^ : S3 



We now state the correctness theorem holding for all the rules presented so far and for the 
few ones that will follow. The proof is partitioned in the following way: here we state the 
theorem, introduce the proof method we adopted and prove the theorem for the simple rules 
presented so far. Then we will introduce more complex rules, like the rule for application, 
and we will prove for each of them the correctness theorem. 

s C T VJ^ TZ^ S'^ £t 

Theorem 3.8 (Correctness). The -w, -w, , and algorithms defined by 

the set of rules presented in this section obey their specification for all admissible ^ relations 

that include the identity for terms in the internal syntax. In particular, the algorithms are 

correct when the identity relation is picked for ^ . 

Proof. We assume the unification algorithm to be correct w.r.t. its own specification. For 
every judgment, the proof is by induction on the proof tree. For each rule, we assume that 
the precondition of the judgment holds for the rule conclusion and that the appropriate 
postcondition holds by induction hypothesis for every hypothesis. We need to prove that 
the precondition of every hypothesis holds and that the postcondition of the conclusion 
holds too. The proofs are mostly trivial for the rules presented so far. In particular, the 

proof for each rule ^ —name or —name follows from the corresponding rule /C— name 
reported in the Appendix [8j 

We will shortly introduce the rules dealing with applicatios together with their correctness 
proofs since applications are handled slightly differently from the way they are processed 
by the kernel. D 
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The next rule deals with applications which are n-ary in our implementation of CIC. In a 
calculus without dependent types, n-ary applications could be handled simply by putting the 

head function type in the form of a spine of n products and then by verifying that the type 
of each argument matches the corresponding expected type. In the presence of dependent 
types, however, it is possible to write functions whose arity depends on the arguments 
passed to the function. For instance, a function / could be given type Vn : N. (repeat N n) 
where (repeat N n) reduces to N — t- . . . — t- N where the number of products is exactly n. For 
this reason, the only possibility is to process applications one argument at a time, checking 
at every step if the function still accepts more arguments. We implement this with an 
additional judgment 



T \- t {xi := Vi : Ti) : ^ v. V 

d "eat products" to 

rule. 



called "eat products" to be specified and implemented immediately after the ( — appl) 



T^t U t' ■ T 



(^ -appl) 



Phi': T I v: V 

V^tu^i v: V 



Specification 3.9 (Eat products (^^)). The ^ algorithm refines an n-ary application by 
consuming an argument at a time. It takes as input a proof problem S, a substitution $ and 
a context F, all assumed to be well formed, the part of the already processed application 
t {xi := vi : Ti) . . . {xr ■= Vr ■ Tr) together with its type T, and the list of arguments yet 
to be checked. The notation (xj := Vi : Ti) means that the i-th already processed argument 
has type Tj and is consumed by a product that binds the variable Xj. The algorithm fails or 
returns the refined application v together with its type V, a new substitution and proof 
problem S'. It is denoted by: 

(S, $) F h t {xr := Vr : Tr) : Tl^ C v: V (S', 

Precondition: 

WJ"(S, F) A S, $, F h : Ti ie{l...r} A J:, T \- t vi . . . Vr : T 

Postcondition (parametric in =^): 

WJ^(S', $') A E',$'<S,«> A T.',^',rhv:V A v 4 t vi . . . Vr ui . . . Uk 

The applicative case is one of the two most complicated rules. Moreover, the refinement 
algorithm for the application does not mimic the one used in the kernel. Therefore we show 

the correctness of the ( —appl) rule and of the implementation of the algorithm. 

Correctness of { —appl). The only rule precondition is WJ-"(S, F) that is also the 
precondition for the first premise. By induction hypothesis on the first premise we know 
S', r \- t' : T where S', are implicitly returned by the first call and passed to 
the second one. Moreover S', <5' < E, $ and t' =4 t- Therefore the preconditions for 
the second premise are satisfied. By induction hypothesis on the second premise we know 
S", r \- V : V where S", are implicitly returned by the second call and by the 
rule as a whole. Moreover T,", < S', $' and v ^ t' Un+l- By transitivity of proof 
problem refinement, we also have S", < E, Moreover, since =<; is admissible, we also 
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have V =4 1^ Un+i =4 t Un+i- All post-conditions have been proved and therefore the rule is 
correct. □ 

The algorithm is implemented as follows. 
(£:^-empty) 



r h t {Xr ■= Vr ■ Tr] '■ T ^ ^ t v^ : T 

Correctness of the empty) rule is trivial. 

rhT>„M nx : Ul.Ti 
r h ui : Ui u\ 



(f^-prod) 



T \- t {xr ■= Vr ■ Tr) {x := u'l : Ui) : Ti[x/u'i\ ^ v : V 

r h t {xr •- Vr : Tr] : T [ ui ^ v : V 



Correctness o/ (f"^— prod). Let S, $ be the well formed pair taken as input by the rule 
and passed to the second premise, that returns the well formed pair E', Similarly, 
let T," , be the well formed pair given in output by the second premise and by the 
whole rule. By induction hypotheses S', < S, $ and S", < E', and thus 
S", < S, $ as required. By the rule pre-condition, T is well typed in E, F and 
so are Ui and Ti obtained by reduction. Thus the premises of the second rule are all 
satisfied and, by induction hypothesis, T,' , ^' , T \- u'l : Ui A u'^ =^ ui. By rules 
/C— appl — rec and /C— appl — base applied to the rule pre-condition t Vi ... Vr T we get 
t vi ... Vr u'l : Ti[x/u[]. Since all preconditions for the third premise are satisfied, by 
induction hypothesis we know S", T ^ v : V and v =4 t vi ... Vr u'^ U2 ... Un. By 
admissibility of ^ we conclude also v ^ t vi ... Vr ui ... Un- Since all post-conditions 
have been proved, the rule is correct. □ 

r h T o^hd ?j or r h T i>^hd ?j wi ...wi 
E E U {T; Xr : ll; x : Ui : Typey} 



(f^-flexible) 



r h T = nx : Ui.?k[Xr/Vr; x/x] ^ 

r \- t {Xr := Vr ■ Tr] {x := u'-y : Ui) : 1 k[Xr / Vr', x / u']\ j 



Un V : V 



V V- 1 {xr := Vr : Tr] : T Imiit ^ V : V 



Correctness of (iS— flexible) . The proof is similar to the one for the f"^— prod rule. We only 
list the major differences here. The fact E', F \- u'l : Ui is now obtained by induction 

hypothesis on the second premise. The role of Ti is now played by Ikixr/vr'jx/x]. The 

induction hypothesis on the third premise yields E'", T h T J, Fix : Ui.lk[xr/vr',x/x] 
that was previously given directly by the rule pre-conditions (up to reduction of T). The 
rest of the proof follows without any changes. The only remaining check to be performed 
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is the well-formedness of 7 k[xr / Vr', x / x] that follows from rule /C— meta using the rule pre- 
condition ^, Tl-Vi-.Ti ie{l...r}. □ 

Another reason for the complexity of the f -^algorithm is the need to infer a dependent 
type for the function / when its type is flexible (a metavariable). We now show an example 
of this scenario and an execution trace for the algorithm. 

Example 3.10 (Inference of a maximally dependent type). Consider the following input, 
where ci, C2, C3, Pi, P2 are such that h ci : N and h C2 : Pi(ci) and C3 : P2(ci, C2): 

{h?,.:Type},0,0hA/:?F./ c, C2 C3 

The rule (f-^— flexible) matches the input and since the argument ci has type N, S is 
extended as follows: 

E = { h?^ : Type; 

x:N h?s 
X : N l-?T : Type} 
Then ?ir gets unified with Tlx : N.?5 obtaining the following substitution: 

$ = {h?^^ := Ux : N.?5 : Type} 

The new type for the head of the application, morally (/ ci), represented as f (x := ci), is 
7s[ci/x]. In the following call to flexible), the argument C2 has type Pi(ci). S is thus 
extended as follows: 

S = { x:N;y:Pi(ci) h?^ :?y; 

x:N;y:Pi(ci) h?v : Type; 
x:N h?5:?r; 
X : N l-?T : Type} 

Then '^s[x/ci] is unified with Hy : Pi(ci).?(/[x/ci] obtaining 

$ = { h?i7 := na; : N.?s : Type; 

x:N h?s:=ny:Pi(x).?[/:?T; 
X : N l-?r := Type : Type} 

The new type for the head of the application (/ ci C2) is ?!7[ci/x; C2/y]. In the following 
call to flexible), the argument C3 has type P2(ci,C2)- S is thus extended as follows: 

S = { x:N;y:Pi(ci);z:P2(ci,C2) h?^ :?ty; 

x:n;y: Pi(ci);z : P2(ci,C2) ■ Type; 

x:N;y:Pi(ci) :?y; 

x:N-y:Pi{ci) h?y : Type} 

Then '^u[x/ci;y/c2] is unified with Hz : P2(ci, C2).?z[a^/ci; y/c2] obtaining 
$ = { h?/,- := nx : N.?5 : Type; 

x:N h?5 :=n2/:Pi(x).?j; :?t; 
X : N \-?T ■■= Type : Type; 
x:N;y: Pi{ci) \-7u := liz : P2(x,y).?z :?y; 
X : N; y : Pi(ci) h?y := Type : Type} 

The final instantiation for ?i? is thus the maximally dependent type 

$(?f) = nx : N.Uy : Pi(x).nz : P2(x,y).?z : Type 
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: tI^.Ii xi Mr) G Env 



S ^ S U {r h?7x, : 
S^SU{rh?t;, : G,[xi/7ur,y^.i/7vJi]} 
Tht: IiTuiTvr'^ t' 



je{i.. 


. n} 




../} 




,.r} 



G^, = iG{l...r} 
T'i = T^xi Pui]^ je{l...n},ie{l. ..n,} 

M'{ = Mi[xi/lui] j G {1 . . . n}, i G {1 . . . r} 

S S U {V h?i : Typey} 

r h r : ny, : Gt.nx : ?5 T' 
(s,$(?i)) G elim(PTS) 



r; y^^._i:P 4_,hP^^=n^ ^ _^ jG{l...n} 

T^t r; yi^ : P^^^ h : T' M'i {kj ?3 y^, ) t^- j G {1 . . . n} 

( -w — matcnj ^ r 

match t in /; return T 



r h T> 



/ return i \ TZ^ 



[h {yl, : P„\) ^ ti I . . . I A;„ : P„"J ^ t„] 

(match t' in Ii return T' \ — y 

[hi {yi,--P'i)^t[ I ... I kn {yZ--P'nJ^t'^]) '''^ '""'^ 

Figure 1: Rule for pattern matching ( —match) 



where 

S = { x:N;y:Pi(ci);z:P2(ci,C2) h?z 

X : N;y : Pi(ci);z : P2(ci,C2) h?iy : Type} □ 

We conclude now the description of the refinement algorithm in type inference mode. 
The final missing rule is the most complicated one and deals with pattern matching. It is 
reported in Figure [Tj 

The rule has been slightly simplified: in the actual implementation of Matita the test 
(s, $(?i)) G elim(PTS) is relaxed to accept elimination of inhabitants of non informative 
data types in all cases under the restriction that the data type must be small. Intuitively, 
smallness corresponds to the idea that the inhabitant of the data type would be non in- 
formative even if declared in Type. Typical examples are empty types and the Leibniz 
equality type. A precise definition of smallness together with the corresponding rules for 
pattern matching can be found in 

Note that the return type T' is usually an anonymous function, beginning with lambda 
abstractions. Thus the type inferred for the pattern match construct is a /3-redex. In fact 
the actual code of Matita post-processes that type firing (r + 1) /3-redexes. 
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Theorem 3.11 (Termination). The algorithm defined by the set of rules presented in 
this section including and is terminating. 

(J 

Proof. The proof is by structural induction of the syntax of terms. The rules ( —ok), 

('^ —variable), ('^ —sort) and ('~^ —constant) are base cases. The first one clearly 

? 

terminates if the unification algorithm = terminates, while the others terminate since F 

and Env are finite and the test (si, S2) G PTS is also terminating. 

c 

Now that we proved that all the rules for amounting to only one for the mono 
directional refiner, terminate, we can consider the ( —default) and ( —ok) as aliases 
for as if we were inlining their code. 

By induction hypothesis (and being now an alias) terminates when called on 
smaller terms. The rule ( — meta) terminates because $ and S are finite, thus lookups 
are terminating, and calls to are done on smaller terms, so the induction hypothesis 
applies. The rule ( — Ictin) calls ^ and ^ on smaller terms, thus terminates by 

induction hypothesis. The same holds for ( —lambda) and ( —product). To prove 
that ( ^ — appl) terminates we use the induction hypothesis on the first premise and we 

are left to prove that terminates as well. Note that calls and on proper 
subterms of the n-ary application, thus the induction hypothesis applies and will be used 
in the next paragraph. 

We show £^ terminates by induction on the list of arguments (i.e. the list of terms 
after j) assuming that the input term T is a well typed type. Thanks to the correctness 

property of ( —appl) always passes to £^ a well typed type. The rule (£^-^— empty) 
clearly terminates. The recursive call in the rule (S^—prod) is on a shorter list of arguments, 

thus is terminating, and the call to ^ terminates by induction hypothesis. The term 
T[x/u'i] is a well typed type thanks to the subject reduction property of CIC, and the 

fact that the variable x and the term Ui have the same type (postcondition of -w, called 
with expected type Ui). The call to i>whci is terminating because T is well typed and CIC 
reduction rules, on well typed terms, form a terminating rewriting system. 

The rule (if "^—flexible) terminates because of the same arguments. The only non obvious 

step is that IIx : Ui.7i;[xr/vr',x/x] is a well typed type. The metavariable ?fe is declared in 
S of type Typey, thus cannot be instantiated with a term. Moreover, since CIC is a full 
PTS, the product IIx : C/i.?fe is well typed of sort Type-r- 

The recursive calls in the last rule (j^— match) are always on smaller terms. We are 

left to prove that the expected type (T' M'I {kj lui yii^)) passed to the recursive call made 

on the last line is indeed a well typed type. The term T is obtained usi ng and we thus 

know it is a function of type Hyr : G^.IIa: : // 7ui The arguments M'i are as many as 

expected and have the right types according to the environment Env (first two lines) and 

thanks to the fact that the substitutions M'^ = M-[xi/7ui] preserves their types. Finally, 

the term {kj lui yi-) has type Ii lui M^ that is the expected one. Thus {T' M'i {kj lui yii^)) 
has type ?i that is a well typed type according to S. □ 
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3.3. Implementation remarks. The choice of keeping S and $ separate is important and 
motivated by the fact that their size is usually very different. While the number of proof 
problems in S is usually small, the substitution $ may record, step by step, the whole proof 
input by the user and can grow to an arbitrary size. Each metavariable must be either 
declared in E or assigned in thus to know if a metavariable belongs to $ it is enough to 
test if it does not belong to S. Knowing if a metavariable is instantiated is a very common 
operation, needed for example by weak head normalization, and it must thus be possible to 
implement it efficiently. 

Another important design choice is to design the kernel of the system so that it handles 
metavariables [4J. This enables to reuse a number of functionalities implemented in the 
kernel also during the refinement process, like an efficient reduction machinery. Also note 
that the extensions made to the type checker described in Definition |2.3| become dead code 
when the type checker is called on ground terms, and thus do not increase the size of the 
trusted code of the system. 

Last, it is worth pointing out that the algorithm is mostly independent from the rep- 
resentation chosen for bound variables. Matita is entirely based on De Bruijn indexes, but 
the tedious lift function is mostly hidden inside reduction and only directly called twice in 
the actual implementation of this algorithm. In particular it is necessary only to deal with 
the types of variables that must be pulled from the context. This potentially moves the 
type under all the context entries following the variable declaration or definition, thus the 
type must be lifted accordingly. 

3.3.1. Rules for objects. Objects are declarations and definitions of constants, inductive 
types and recursive and co-recursive functions that inhabit the environment Env. Exactly 
like terms, the user writes objects down using the external syntax and the objects need to 
be refined before passing them to the kernel for the final check before the insertion in the 
environment. 

Definition 3.12 (Type checking for objects (Env h WF)). The type checking algorithm 
for CIC objects takes as input a proof problem S and a substitution <I>, all assumed to be 
well formed, and an object o. It is denoted by: 

EnvU(S,$,o) h WF 

and states that o is well typed. 

This algorithm is part of the kernel, and described in Appendix [8j It is the basis for 
the construction of the corresponding refinement algorithm for objects, that is specified as 
follows. 

Specification 3.13 (Refiner for objects (TZ)). A refiner algorithm TZ for CIC objects takes 
as input a proof problem S and a substitution all assumed to be well formed, and an 
object 0. It fails or returns an object o', a proof problem T,' and substitution It is 
denoted by: 

(S, $) h o o' (S', 

Precondition: 

W-F(S, 
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Postcondition (parametric in ^): 

A S',«>'<S,$ A EnvU(S',$',o') h WF A o'^o 

Note that an object can be a block of mutually recursive definitions or declarations, 

each one characterized by a different type. Thus the rule does not return a single type, 
but a new object together with a new metavariable environment S' and substitution 
When S' is not empty, all the metavariables in S' correspond to proof obligations to be 
proved to complete the definition of the object, necessary to convince the system to accept 
the object definition. This is especially useful for instance in the formalization of category 
theory where definitions of concrete categories are made from definitions of terms (objects 
and morphisms) together with proofs that the categorical axioms hold. In such definitions, 
objects and functors are immediately fully specified, while the proof parts are turned into 
proof obligations. Spiwack's Ph.D. thesis [31] discusses this issue at length as a motivation 
for a complete re-design of the data type for proofs in Coq. The new data type is essentially 
the one used in this paper and it will be adopted in some forthcoming version of Coq. The 
old data type, instead, did not take the Curry-Howard isomorphism seriously in the sense 
that partial proofs were not represented by partial proof terms and the refinement of an 
object could not open proof obligations. This problem was already partially addressed by 
Sozeau [29j where he added a new system layer around the refiner to achieve the behavior 
that our refiner already provides. 

, TZ . \-T ^T' : s 
—axiom) 



TZ 

h axiom c : T axiom c : T' 



hT -^T' -.s ht:T' Ut' 
( —definition) 



TZ 

h definition c : T := t definition c : T' := t' 



> > 

^ ^ 

^ ^ ' ^ 

S ^ S U {x; : 4; yj~i ■■ R'j-i : R'j} je{l...r^} 



, TZ . , , . ^ xi : Lf,In A^; Zp : Vp. ^. h Vi^k = li xi 
( — mductivej - 



i G {1 . . . n} 



i G {1 . . .n} 
k e {I. ..uin} 



TZ 



'Uxi : Li. inductive h : A\ := ki^i : Ti^2 \ ■■■ \ h,mi ■ Ti^rm 

with ... I ^ 

with Iji : An '■= kn,l '■ T^^l | . . . | kn,mn '■ Tn^rrin 

'Uxi : L\. inductive h : A[ := fcij : r{_2 | • • • | ki,mi ■ T[^^^ 
with . . . 

with In '■ An '■= kn,l '■ \ ... | kn^m„ ■ 



^ n,mn 



The loop from 1 to n, ranges over all mutually inductive types of the block using the index 
i (for inductive). The other loop, from 1 to m„, ranges over the m„ constructors of the n-th 
inductive type using index k (for constructor). T-i^k is the type of the A;-th constructor of 
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the i-th inductive. Every inductive type in the block has the same number of homogeneous 
parameters / of type Lq, for some a in 1 ... /, and extra arguments of type i?^ for some /3 
in 1 . . . r j . As explained in Section [2j homogeneous arguments are not abstracted explicitly 
in the types of the constructors, thus their context includes not only the inductive types 
/„ but also the homogeneous arguments Note that in this rule we used In to mean the 
n-th inductive, in contrast with the rest of the paper where the index n means the number 
of homogeneous arguments, I here. The complete arity of the inductive types V is a closed 
term. In fact that type is generated in an empty context in the first premise. This makes 
the context in which Tj ^ is processed valid: there is no variable capture when Icl is put 

before /„. Moreover the successful refinement of IIx; : Li.Ai in the empty context grants 
that the types of the homogeneous arguments do not depend on the inductive types In- 
The last three premises just check that the type of each constructor is actually a product 
targeting the inductive type. 

Whilst being already quite involved, this rule is only partial. It lacks the checks for 
positivity conditions, that are only implemented by the kernel. Since the kernel of Matita 
is able to deal with metavariables we can test for these conditions using directly the kernel 
after the refinement process. Nevertheless, when the inductive type fed to the kernel is 
partial, the checks cannot be precise: all non positive occurrences will be detected, but 
nothing will prevent the user from instantiating a missing part with a term containing a 
non positive occurrence. One could label metavariables in a such a way that the unification 
algorithm refuses to instantiate them with a term containing non positive occurrences of 
the inductive type, but our current implementation does not. Anyway, once the definition is 
completed by the user, another call to the kernel is made, and all non positive occurrences 
are detected. 

Moreover, the kernel also checks that the sort Sj^^ of the type of every constructor Tj /; 
is properly contained in the sort of the corresponding inductive Sj. Finally, one should also 
check that any occurrence of /j in the types Tj ^ of the constructors is applied to x;. This 
test is also omitted since it is performed by the kernel during the test for positivity. 



(S. -letrec) fn-Tn;x\,^: T'l^^U^ r\,^^, ^ t', J 

^ / let rec /i (x^^ : T p\ ) : T^^j^^ := ti and . . 

( let rec ^^' pj : ^pi+l := *i and 

\ and fn{Xp^:T'pJ : T' ^^^j^^ := t'n 

As for inductive types, this rule is only partial: it lacks the checks for guardedness conditions 
(termination or productivity tests), that are delegated to the kernel. We omit the rule for 
co-recursive functions, since it is identical to the one presented above. 
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4. Bl-DIRECTIONAL REFINEMENT 

To obtain a bi-directional implementation of the refiner, we add new rules to the al- 
gorithm. These ad-hoc rules for particular cases must take precedence over the generic 
( —default) rule. The ad-hoc rules are responsible for propagating information from the 
expected type towards the leaves of the term. 

The new rule for lambda-abstraction is well known in the literature |24j and it is also 
the only one implemented in Coq. The rule for let-in statements is given to allow the system 
infer more concise types. The one for application of constructors is completely novel and it 
takes advantage of additional knowledge on the constant parameters of an inductive type. 
It is thus peculiar of the Calculus of (Co)Inductive Constructions. This is also the rule that, 
according to our experience, mostly affects the behavior of the refiner. It makes it possible 
to refine many more terms to be refined in frequently occurring situations where, using a 
mono directional algorithm, more typing information had to be given by hand. 

Theorem 4.1 (Correctness). The new rules given in this section do not alter the correctness 

of the algorithm w.r.t. its specification for all admissible ^ relations that include the 
identity for terms in the internal syntax. In particular, the algorithm is correct when the 
identity relation is picked for =<( . O 

Ph^^whd Ilx:Ei.E2 

r h T 5^ T' : s 

rhT' = Ei ^ 

^TZ^ ^ T;x:T'ht: E2 ^ t' 

( —lambda) 



Xx:T.t: E Xx : T .t' 



Note that to type t we push into the context the declared type for x and not its expected 
type El. This is to avoid displaying a confusing error message in case t is ill- typed, since 
the user declared x to have type T, and not Ei (that in principle can be arbitrarily different 
from r). 

r h T ^> T' : s 

r h t : r U t' 

,7e* T;x ■.= t' -.T' h u: E[t'/x] U u' 



( — letin) 



77 -O- 

r h let (x : T) := tin n : E ^ let {x : T') := t' in u' 



Where we denote by [t' /x] the operation of substituting all occurrences of t' with x. Note 
that this operation behaves as an identity up to conversion (since x holds the value t'). 
Nevertheless, it enables the bi-directional type inference algorithm to propagate smaller 
types towards the leaves and, according to our observation, it leads to more readable inferred 
typed for sub-terms of u' . 

Theorem 4.2 (Termination). The algorithm defined by the set of rules presented above 
with the addition of ( —letin) and ( —lambda) terminates. 
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Proof. The two functions terminate because all recursive calls are on smaller terms and 

jr ? 

because >whd) ^ and = terminate. □ 

The next rule deals with applications of constructors to arguments and it is only trig- 
gered when the expected type is an inductive type. In that case the application must 
be total. In CIC, the types of constructors of inductive types are constrained to have 
a particular shape. Up to reduction, their type must be of the form IIxi : Fi . . . lixn : 
Fn-I xi ... xi . . . tm where I is the number of uniform parameters of the inductive 
type. Therefore the application of a constructor to a list ui . . . of arguments has type 
I ui ... V4 vi^i . . . Vjn for some vs. Reversing the reasoning, once we know that the ex- 
pected type for the application of a constructor is / tii ... ui v^+i ... we already know 
that the first I arguments of the application must be equal to ui ... ui up to conversion. 
It is thus possible to propagate them following the bi-directional spirit. This is achieved 

by the following ( — appl— A;) that calls a new function denoted by St that consumes the 
first I arguments unifying them with the expected values. The remaining arguments are 
consumed as in the generic case of applications. 

T\- E o„hd Iiviw^ 

r\- tm^ Vl ti I Uo 

{k:T)e Env 

T\-T>^M^xi : ^i.r 

T\-k~^i : T'[^i\ ^ r: R 

,11"^ , V\- R = Ii^i wti ^ 



( — appl— /e) 

Note that if E does not reduce to an applied inductive type, the implemented algorithm 



T^ktZ: E U r 



falls back to the standard rule for application. 

The rule presented only propagates information related to uniform parameters. Uniform 
parameters must be used consistently in every occurrence of the inductive type in the type 
of its constructors and not only in the occurrence at the end of the product spine (i.e. in 
the return type of the constructors). The variant of CIC implemented in Coq also considers 
non uniform parameters. Non uniform parameters must be used consistently only in the 
return type of the constructors and not in the premises. We do not consider non uniform 

parameters in this paper, but we remark that the ( —appl— A;) rule is also valid when the 
first I parameters are non uniform. 

Specification 4.3 (Eat arguments {£t))- The ~4 algorithm takes a list of arguments for an 

application and a list of terms, and it verifies that an initial prefix of the arguments is equal 
to the given terms, up to unification. It takes as input a proof problem S, a substitution $ 
and a context F, all assumed to be well formed, the list of arguments and the list of terms. 
It fails or it returns the list of arguments split into the consumed ones and the ones yet to 
be considered. It is denoted by: 

(S, $) r h ti ...trn^V^ ... Vn ^ A • ■ • 4 1 ^1 ■ ■ ■ ^1 (S', 

Precondition: 

>VJ^(S, r) A 11, ^, Vi-.Ti ie{l...n} 
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Postcondition (parametric in 

WJ^{T.', A S',$'<E,$ A J:' , ^' , T \- t'i i Vi ie{l...n} A 

t[ ... 4 Ui ... Ul 4ti ... tm 

-empty) — 



base) 



r h ii U t[ : Ti 
r I- ti C ^ ^^1 *'l *n 1 ^ 



Theorem 4.4 (Termination) . The algorithm defined by the set of rules presented above 
with the addition of { — appl — k), (f^— empty) and (<?<— base) terminates. 

Proof. The rule ( ^ —appl — k) terminates because = and >„hd terminate and £^ is called 

on smaller terms. Moreover the term T'[xi/t'i] is a well typed type because £t grants that 

are convertible with and thus have the same types. Also notes that all the calls to 

^ made by £t are on sub-terms of the input of ( —appl — k). 

We thus show that £t terminates by induction on the second list of arguments (the 

one between = and ). Rule {Sf— empty) is the base case and clearly terminates. Rule 

(£^t— base) terminates because and = terminate and because the recursive call terminates 
by induction hypothesis. □ 



4.1. Remarks. We present here a simple but frequently occurring case that explains why 
the bi-directional rule for application of constructors enables to refine many more terms 
w.r.t. the mono-directional algorithm. A more complicated example was already discussed 
in the introduction and deals with dependent data types to represent the syntax of languages 
with binders. 

Consider the inductive type used to define the existential quantification. 

nr : Type.nP : T Prop, inductive Ex : Prop := 

ExJntro : Ux : T.P x^ExT P 

Note that T and P are homogeneous arguments. 

Example 4.5 (Use of ( —appl— A;)). Consider the conjecture 3x : N.x > 0, encoded in 
CIC as 

Ex N (Ax : N.x > 0) 

Given a context T containing the assumption p stating that 2 > 0, one may want to use the 
following proof term to prove the conjecture 

t = ExJntro "!t "^p "^-x P 
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A mono directional refiner encounters a hard unification problem involving the type of p, 
2 > 0, and its expected type. 

{h ?r : Type; h ?p : ?t ^ Prop; h : ?T},0,r h 2 > =?p'!^ 

Clearly, the desired solution is to instantiate ?x with 2 and ?p with (Ax : N.x > 0) obtaining 
a proof term of type 3x : N.x > 0. Unfortunately, this is not the only possible solution. An 
undesired solution, but as reasonable as the correct one, is 

$ = {?^ := N; ?cc ■■= 0; ?p := Xx : N.2 > x} 

under which the resulting proof term has type 3x : N.2 > x, that is not the expected 
one. Why one should prefer the former to the latter is also unclear from a computer 
perspective. Thanks to the polymorphism of CIC, another undesired and less expected 
solution is also possible: 

= {?T := Prop; 7^ := 2 > 0; ?p := Xx.x} 

The proof term ^'{t) would then be of type 3x : Prop.x, again different from the desired 
one. 

Using the expected type, ?p and ?p are easily inferred looking at the homogeneous 
argument of the expected type. 

= {?T := N; ?p := Ax : N.x > 0} 

Then inferring ?x is easy. Applying to the right hand side of the unification problem we 
obtain: 

2 > = (Ax : N.x > 0) ?^ 
Then it is sufficient to reduce the right hand side and then perform a simple, first order, 
unification algorithm to obtain the desired instantiation for ?x- O 

The rule ( — appl— A;) is only fired when the term to be refined is syntactically the 
application of a constructor. Because of conversion, the term under analysis could be 
reducible to an application of a constructor. However, we cannot reduce the term first to 
try to match the rule. The first motivation is that terms in the external syntax may contain 
placeholders (see Section [s]) and may not be well typed. Duplication of placeholders and 
substitution into them is not admitted. Moreover, reducing an ill typed term may lead to 
divergence. Secondly, reduction of proof terms correspond to cut elimination that is known 
to yield proofs terms of arbitrary size. 

5. Extension to placeholders 

We consider here the first extension of our external syntax, obtained introducing linear 
placeholders for missing terms and for vectors of missing terms of unknown length. The 
latter are only accepted in argument position, even if we will enforce this only in the 
refinement algorithm and not in the syntax. The new syntax is obtained extending the 
one given in Table [T] with the new productions of Table [2| Placeholders are also called 
implicit arguments in the literature, but that terminology is ambiguous since it is also used 
for arguments that can be entirely omitted in the concrete syntax. 

In a concrete implementation, user defined notations are used to further enlarge the 
external syntax. User defined notations behave as macros; macro expansion gives back a 
term in the external syntax we consider here. In particular, thanks to user defined notations. 
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placeholder 

arbitrarily many placeholder arguments 



? 



Table 2 



CIC terms syntax II - Placeholders 



it is possible to entirely omit the typing information in binders, like in calculi typed a la 
Curry. Omitted types are turned into placeholders during the macro expansion phase. 
Implicit arguments can also be simulated by defining notations that insert into applications 
a fixed number of placeholders or vectors of placeholders in appropriate positions. 

A placeholder ? differs from a metavariable ?i in the fact that it has no sequent associ- 
ated to it. The intended associated sequent allows in ? occurrences of all variables in the 
context of ?. Moreover, the type of ? is meant to be the one determined by the context. 
This information is made explicit by the refinement algorithm that turns each placeholder 
into a corresponding metavariable. 

Placeholders occur only linearly in the term (i.e. every occurrence of a placeholder is 
free to be instantiated with a diff'erent term). Non linear placeholders are not allowed since 
two occurrences could be in contexts that bind different set of variables and instantiation 
with terms that live in one context would make no sense in the other one. 

Similarly, substitution is not allowed on placeholders since a placeholder occurrence 
does not have a corresponding explicit substitution. 

For both previous reasons, reduction is not allowed on terms in the external syntax 
that contain placeholders: the reduction, conversion and unification judgements only make 
sense on refined terms. 

Intuitively, a vector of placeholders can be instantiated by the refiner with zero or more 
metavariables. In our algorithm we adopt a lazy semantics: vectors of placeholders can 
only be used in argument position and a vector is expanded to the minimal number of 
metavariables that make the application well typed. Bi-directionality, i.e. the knowledge 
about the expected type for the application, is required for the lazy semantics. Indeed, 
without the expected type, an expansion could produce a locally well typed application 
whose inferred type will not match later on with the expected one. 

T^fr 7^4 £-T £^ 

We extend the and algorithms with new rules for single placeholders 

and for vectors of placeholders. 

Theorem 5.1 (Correctness). The ^ , and algorithms extended 

with the set of rules presented in this section obey their specification for all admissible 
=4 that include the =4' relation defined as follows: t' =4' t when t' is obtained from t by 
replacing single placeholders with terms and vectors of placeholders with vectors of terms. 
In particular, the algorithms are correct w.r.t. ^' . 

Proof. Every admissible =<; that includes ^' also includes the identity. Thus we do not need 
to re-establish the result on the rules given in the previous sections. Correctness of the new 
rules given in this section is established by rule inspection. □ 




placeholder) 



S ^ S U {r h?z : TypBT , T h?,, : , P h?,- : 
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( —placeholder) -— 

r h? : T U ?fe 

r h t {xr •- Vr ■ Tr] : T j S v : F 



{£ — placeholder —0) 



£T 



V\- t (Xr := Vr : Tr) ■ T I ? Un V : V 

ri-r>^hdnxi : Ui.Ti 



, rr > , T ^ t ixr := Vr -.Tr) : T \ 1 1 ^ U v. V 

{S^- placeholder +1) ^ r r) ^_ 

Vht{xr ■- Vr ■ Tr) : T I ? 11^, V : V 



The rule {£ — placeholder —0) is meant to take precedence over {£ — placeholder +1). 

The second is applied when the first one fails (local backtracking). 

Theorem 5.2 (Termination). The algorithm defined by the set of rules presented above 
with the addition of ( —placeholder), ( —placeholder), 
{S^— placeholder —0) and {S^— placeholder +1) terminates. 

Proof. Rules ( ^ —placeholder) and ( ^ —placeholder) terminate. The proof that £^ 
terminates is, as before, by induction on the list of arguments that follow |. The rule 

{£^— placeholder —0) terminates by induction hypothesis. The rule {£^~ placeholder +1) 
deserves an accurate treatment. The check over T, asking it to be a product, is to avoid 
divergence. Since the input T is a well typed type, also Ti is, and thus it admits a nor- 
mal form T[ in which x may occur. The recursive call docs necessarily trigger the rule 
(f^— product) that will substitute a metavariable 7j for a; in Ti. Thanks to the reduction 
rules of CIC, reported in the appendix, substituting a variable for a metavariable declared 
in S (and not in $) does not change the normal form, meaning that T[[x/lj] >vfiiAT[[x/lj\. 

-c- 

Thus the rule {£'^ — placeholder +1) can be applied only a finite number of times, and the 
number of products in T is an upper bound. □ 

St £^ 
The next two rules for the judgment follow the same schema of the ones for . 



{£t— placeholder —0) 



■n 1-9" ^ ^ £t 7^ \ ^ 

r h ? tm = Vn t'r^ I Ul 



" , T 1 i^, = J^, I',, I 4 

{£t- placeholder +1) _^ ^ „ — ^ 

r h ? tm = Vn t'r,l Ui 

Theorem 5.3 (Termination). The ^ algorithm defined by the set of rules presented above 

> > 

with the addition of {£t— placeholder —0) and {£t— placeholder +1) terminates. 
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Proof. The rule {£t— placeholder —0) makes a recursive call on the same list of arguments 

— o 

Vn but consumes a ? , and no other rule of the refiner adds one, so it can be repeated only a 

finite number of times. The recursive call in the rule {£t— placeholder +1) can trigger only 
rules (ff— empty) and base). The former terminates immediately, the latter will do a 
recursive call consuming one argument in v^, and thus terminates. D 

Note that inlining the latter would lead to a rule whose termination is trivial to see, 
but we preferred to present the algorithm in a more modular way. 

Example 5.4 (Vector of placeholders). Assume a theorem r G Env shows that Vx : N.P x — )• 
Q X. The proof context may contain a natural number y and optionally a proof H that y 
validates P. Different proofs or proof styles may use the same theorem r in different ways. 
For example, one may want to perform forward reasoning, and tell the system to assume 
(Q y) providing the following proof for it 

y ■.n;H : P y^ T H 

Nevertheless, sometimes H is not known, and the user may want to tell the system he has 
intention to use the theorem r on y, and prove (P y) later. 

y : N h r y 

While the latter application is well typed, the first is not, since the first argument of r must 
be of type N. Nevertheless, the type of H depends on y, thus the term (r ? H) would refine 
to the well typed term (r y H) of type {Q y). 

The vector of placeholders enables the system to accept both terms originally written by 

— o 1> 

the user. In the first case (r ? H) would expand to (r ? H) thanks to {£t— placeholder +1), 

— 1> 

and refine to (r y H). In the second case (r ? y) would refine to (r y) thanks to 

—> — o 

{£t— placeholder —0). This suggests defining (r ? ) as a notation for the theorem r, obtain- 
ing a cheap implementation of what other systems call prenex implicit arguments: the first n 

arguments of an application whose head has a dependent type like IIx^ : Tn.Uym '■ P{xn)-T 
can be omitted, and are inferred thanks to the dependencies in the types of the m following 
arguments. As a bonus, in case the user wants to pass one of the implicit arguments there 

— 1> 

is no need to temporarily disable the mechanism, since the expansion of ? is computed on 
the fly and automatically adapts to its context. □ 



6. Coercions 

Coercions are explicit type casts. While the literature considers them mostly as a device 
to mimic sub- typing in a calculus lacking it, they have other interesting applications. The 
refiner of Matita inserts coercions in three locations: 

• around the argument of an application 

• around the head of an application 

• around the type of an abstraction 

The first case is the most common one, and is the one that can easily be explained in 
terms of sub-typing. For example, if one applies an operation defined over integers Z to an 
argument lying in the type of natural numbers N, the system injects the argument into the 
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right type by means of the obvious, user declared, cast function mapping naturals into the 
non negative fragment of Z. 

The second case is handy in two situations. First when the head of the application 
is implicit in the standard notation, like in 3x where the intended head constant is the 
multiplication but in the input it happens to be 3. The second is when the head constant 
has a non ambiguous interpretation as a function, but is not. For example a set may act as 
its characteristic function. 

The last case is recurrent when algebraic structures are encoded as dependently typed 
records [25] embedding the type (or carrier) for the elements together with the operations 
and properties defining the structure. In that case, one may want to state a theorem 
quantifying over a structure G, say a group, and some elements in that group. However the 
statement VG : Group.Vx, y : G.P{x, y) is ill-typed since G is a term (of type Group) but is 
used as a type for x and y. The intended meaning is clear: x and y lie in the carrier type 
of G. The system can thus insert around G the projection for the carrier component of the 
Group record. 

Definition 6.1 (Coercion set (A)). A coercion set A is a set of pairs (c, /c) where c is a 
constant in Env and A; is a natural number smaller than the arity of c (i.e. k points to a 
possible argument of c) 

In the literature the coercion set is usually represented as a graph. Given a coercion 
(c, fc) such that (c : IIxi : Ti . . .lixk ■ Tk-.-Hxn '■ Tn-T) £ Env, Tk and T are nodes in 
the graph, and c is an edge from to T. Most coercion implementation, like the one of 
Coq, Lego and Plastic, assume A to be a graph validating a property called coherence. 
This property states that A is an acyclic graph with at most one path linking every pair of 
nodes. This property enables to employ a straightforward algorithm to look for a sequence 
of coercions linking two non adjacent nodes in the graph. 

In Matita, for various reasons detailed in [34j, A is not a graph, but a set of arcs for the 
transitive closure of the graph. Every time a coercion c is declared by the user, and thus 
added to A, the following set of automatically generated composite coercions is also added 
to A. 

{ci o c o Cj\ci £ A A Cj G A} U {c o Cj\cj G A} U {cj o c\ci G A} 

Of course the o operator here is partial, and only well typed composite coercions are actually 
considered. This design choice enables the coercion lookup operation to be single step, 
since the set is already transitively closed. Moreover, since composite coercions are defined 
constants in Env, the term resulting after a cast is smaller if compared with the one obtained 
inserting the corresponding chain of user declared coercions. Last, allowing k to differ from 
n is a peculiarity of Matita. When k ^ n the application of the coercion creates new 
uninstantiated metavariables that correspond to proof obligations. This will be detailed 
later on. 

The last detail worth mentioning is that, all systems known to the authors with the 
notable exception of Plastic [9j, adopt some approximated representation for the nodes in the 
coercion graph, usually the name of the head constant of the source and target types. This 
results in a faster lookup in the coercion graph, but the coherence check is also strengthened. 
In particular, in a calculus with dependent types, different, but similar, coercions may not 
be allowed to be declared. Matita drops the coherence check, or better changes it into a 
warning, and enables the user to attach to coercions a priority: coercions from and to the 
same approximation of types are all tried according to user defined priorities. 
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Specification 6.2 (Coercion lookup — A)). Given a context F, substitution ^ and 
proof problem S, all assumed to be well formed, two types Ti and T2, this function returns 
an explicit cast c ?i . . . ?fc • • • ?n for the metavariable of index k and its type T'. It is 
denoted by: 

(S, r h Ti ^ r2 ^ k, c7i ... ?fc ...?„: T' (S', 
Precondition (parametric in ~): 

>VJ"(S, r) A {c,k)e A A (c : nxi : Ti . . . Uxk : Ifc . . . nx„ : T^.T) e Env A 

Tfe « Ti A T « T2 

Postcondition: 

>VJ-(s') A s', r h c ?i . . . ?fc . . . ?n : r' 

We denoted by ~ the approximated comparison test used to select from A a coercion c 
from Ti to T2. A proper definition of ~ is not relevant for the present paper, but we can 
anyway say that Matita compares the first order skeleton of types obtained by dropping 
bound variables, metavariables and higher order terms, and that this skeleton can be made 
less precise on user request. We will give an account of this facility in the example that will 
follow. 

The new metavariables ?i, . . . , ?„ generated by the lookup operation are all declared in 
the new proof problem T,' . The number of metavariables to which c is applied to is defined 
when the coercion is declared and may be less than the arity of c. In the latter case T 
is a product and the coercion casts its fc-th argument to be a function. The position k of 
the casted argument is user defined as well. The coerced term has then to be later unified 
with 

Theorem 6.3 (Correctness). The , and ^ algorithms extended with 

the set of rules presented in this section obey their specification where ^" is the following 
admissible order relation: t' =4" t when t' is obtained from t by replacing single placeholders 
with terms, vectors of placeholders with vectors of terms, and terms Uk with terms convertible 
to {c ui ... Uk ... Un) where c is a coercion declared in A for its k^^ argument. 

Proof. We do not need to re-establish correctness for the rules given in the previous sections 
since ^" is admissible and includes Correctness of the new rules given in this section is 
established by rule inspection as usual. □ 

In the following rule the coercion c is applied to its argument t unifying it with 7^. The 
returned term t' can still contains metavariables: ?i . . may appear in the type of 7^, 
thus unifying 7^ with t may instantiate thenj^ but 7fc_|_i . . .7„ do not appear in the type 
of 7i . . .7fc, and thus cannot be all instantiated. This rule is applied as a fall back in case 

— ok fails. 



In the case of dependent types the unification of the types is a necessary condition for the unification of 
the two terms, as claimed by Strecker |32| . 
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( ^ —coercion) 



T\-Ti^T2 ^ k, c'C'^k'C: 

r h?fe = t ^ 
rhT^ = r2 ^ 

r\-t:Ti = T2 ^ clZh'^n 



Correctness of { —coercion). Since 7^ is unified with t in the second premise of the rule, 
by definition of unification we have E, F 1-?^ J, t, and thus c ?m "^k "^n t- Moreover, 

the postconditions of coercion lookup grant that c 7^ 7„ has type T2 that is later 
unified with T2 . Thus the postconditions of the unification algorithm allow us to prove that 
c 7m 7fc 7„ has a type convertible with T2. D 
c 

The ^ —coercion rule automatically takes care of the insertion of coercions around 
arguments of an application and around the types of an abstraction. 

The following extension to take cares of insertion around the head of an application. 

S S U {r h7i/ : TypeT , T h?i : 7i/} 

S ^ E U {F; :7i l-?^' : Typer , F; xi :7i h72 : 72'} 

Fhti^:T = n.x:7i.72 ^ cwt 
Tl-Wi-.Wi ie{l...s} 



(£^'^— coercion) 



F h c (xs := Ws : Ws) : Ux :7i.72 | ^ : V 

F h t (x^ := Vr : T^S : T [ m S t; : y 



Correctness 0/ £^'^— coercion. Its correctness follows trivially from the correctness of ( ^ 
—coercion) . □ 

Theorem 6.4 (Termination). The algorithm defined by the set of rules presented above 
with the addition of { —coercion) and (£^'^— coercion) terminates. 



Proof. Rule ( —coercion) clearly terminates. The rule (£^'^— coercion) issues a recursive 

call to without consuming ui, but the only rule that can be triggered is (£^'^— product), 
that will immediately consume ui. □ 

Inlining (<S^— product) would result in a rule that consumes some input and thus clearly 
terminates, but would be way less readable. 
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6.1. Implementation remarks. Since we allow coercion arguments not to be inferred 
automatically (like proof obligations) their type may depend on the coerced term (e.g. the 
proof that the coerced integer is greater than zero has an instance of the coerced integer in 
its type, and the corresponding metavariable will have index greater than k). 

Example 6.5 (Coercion with side conditions). Consider the following coercion set, declar- 
ing the coercion v_to_nel from vectors to non empty lists. 

A = {(v_to_nel, 3)} 

The environment holds the following type for the coercion: 

(v_to_nel : UA : Type. Tin : N.IIi; : Vect A n.n > ^ 31 : List A, length / > 0) G Env 

Now consider the term t = (Vcons N (Vnil N) 2) and the following coercion problem: 

r h Vect N (0 + 1) ^ {31 : List N, length / > 0) ^ 
3, v_to_nel ?i ?2 ?3 ?4 : (31 : List ?i, length / > 0) 

r h?3 = t ^ 

Th {31: List ?i, length I > 0) = {31 : List N, length / > 0) 

r h t : Vect N (0 + 1) = (3/ : List N, length / > 0) v_to_nel ?i ?2 ?3 ?4 
where the final proof problem and substitutions are: 

S = {F h?4 : ?2 > 0} 

$ = {r h?i := N : Type, L h?2 := + 1 : N, T h?3 := t : Vect N (0 + 1)} 
Note that ?4 is still in S, thus it represent a proof obligation the user will be asked to solve. 
Also note that the following coercion could be declared as well, with a higher precedence. 
It is useful since it does not open a side condition when the type of the coerced vector is 
explicit enough to make the proof that it is not empty constant (not depending on F nor 
on the vector but just on its type) and thus embeddable in the body of the coercion. 

(nev_to_nel, UA : Type.IIn : N.Uv : Vect A {n+ l).3l : List ^, length / > 0) G Env 

The system would thus try nev_to_nel first, and fall back to v_to_nel whenever needed. □ 

Also note that this last coercion can be indexed as a cast from (Vect _ (_ + 1)) to 
{31 : List _, length /> 0) or in a less precise way. For example the approximation of the 
source type could be relaxed to (Vect _ _). This will force the system to try to apply this 
coercion even if the casted term is a vector whose length is not explicitly mentioning +1, 
but is something that unifies with ?j + 1. For example the length 1*2 would unify, since 
its normal form is (0 + 1) + 1. 

7. Comparison with related work on Type Inference 

Type inference is a very widely studied field of computer science. Nevertheless to the 
authors' knowledge there is no precise account of a type inference algorithm for the full 
CIC calculus in the literature. 

The extension to the typing algorithm of CIC with explicit casts in [28] follows the 
same spirit of our refinement algorithm for raw terms. However the work by Saibi does not 
handle placeholders nor metavariables, and the presentation is in fact quite distant from 
the actual implementation in the Coq interactive prover. 
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Another work in topic is [22J where Norell describes the bi-directional type inference 
algorithm implemented in the Agda interactive prover. He presents the rules for a core 
dependently typed calculus enriched with dependent pairs. Unfortunately he omits the 
rules for its extension with inductive types. It is thus hard to tell if Agda exploits the type 

expected by the context to type check inductive constructors as in rule ( — appl— A:). 

— c- 

Agda does not provide an explicit ? placeholder but uses the expected type to know when 
it is necessary to pad an application with meta variables in order to reduce the arity of its 
type. In our setting this is equivalent to the following transformation: every application 

— 1> 

(/ a ) is turned into {fa ? ) whenever its expected type is known (i.e. not a metavariable). 

One aspect that allows for a direct comparison with Coq and Agda is the handling of 
implicit arguments. In both Agda and Coq, abstractions corresponding to arguments the 
user can freely omit are statically labelled as such. The systems automatically generate 
fresh metavariables as arguments to these binders and the type inference algorithm even- 
tually instantiates them. Both systems give the user the possibility to locally override the 
implicit arguments mechanism. In Coq the user can prefix the name of a constant with the 
@ symbol, while in Agda the user can mark actual arguments as implicit enclosing them in 
curly braces. This escaping mechanism is required because many lemmas admit multiple 
and incompatible lists of implicit arguments. 

As an example, consider a transitivity lemma eqt : Vx, y, z.x = y^y = z^x = z. When 
used in a forward proof step the user is likely to pass as arguments a proof p that a = h and 
a proof q that b = c like in (eqt p q) to put in his context the additional fact a = c. In that 
case values for x,y and z are determined by the types of p and q. On the contrary if the 
lemma is used in backward proof step to prove that a = c, no value for y can be inferred, 
thus the user is likely to use the lemma as in (eqt b) and expect the system to open two 
new goals: a = b and b = c. The two different uses of eqt make it impossible to statically 
attach to it a single list of implicit arguments and at the same time to never resort to an 

escape mechanism to temporarily forget that list. 

— > 

In Matita the user can simply use the ? placeholder, thus no escaping mechanism is re- 
quired. In fact the type inference algorithm described in this paper lets the user write 

(eqt ? p q) in the first case as well as (eqt ? c) in the second onej^ 

The lack of a complete and formal study of type inference for raw CIC terms is probably 
due to the many peculiarities of the CIC type system, in particular inductive and dependent 
types, explicit polymorphism and the fact that type comparison is not structural, but up to 
computational equivalence. We thus try to position our work with respect to some of the 
main approaches adopted by type inference algorithms designed for programming languages. 

7.1. Greedy versus delayed constraint solving. The most notable example of type 
inference algorithm based on constraint solving is the one adopted for the Agda system f22] . 
Agda is based on a dependently typed programming language quite similar to CIC, but is 
designed for programming and not for writing proofs. The type inference algorithm collects 
constraints and checks for their satisfiability. Nevertheless, their solution is not recorded in 
the terms. This enables the user to remove an arbitrary part of an already type checked 



trailing ? is automatically added to any term used in backward proof step. 
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term and have the typing of its context not influenced by the term just removed. While 
this "compositionality" property is desirable for programming in a language with dependent 
types, it is not vital for proof systems, where one seldom edits by hand type checked terms. 

A strong characteristic of constraint based type inference is precise error reporting, as 
described in |33| . Even if it the heuristics adopted in Matita [27] to discard spurious error 
reports are slightly more complex than the ones proposed by Stuckey, we believe that they 
provide a similar precision. 

Greedy algorithms like the one presented in this paper, are characterized by a 
very predictable behavior, at the cost of being forced to take early decisions leading to 
the rejection of some possibly well typed terms. Also remember that unification has to 
take computation into account, and user provided functions are known to be total only if 
they are well typed. Thus the resolution of type constraints cannot be delayed for long. 
According to our experience, predictability compensates for the extra type annotations the 
user is sometimes required to produce to drive the greedy algorithm towards a solution. 

7.2. Unification based versus local constraint solving. Many algorithms to infer a 
polymorphic type for a program prefer to avoid the use of unification [23] since unification 
variables may represent type constraints coming from distant, loosely related, sub-terms. 
Moreover a bi-directional approach pushes the type constraints of the context towards sub- 
terms, making it effectively possible to drop unification altogether. These approaches also 
scaled up to types with some sort of dependency over terms, as in [T5| . 

Interactive provers based on type theory are for (good and) historical reasons based on 
the two twin approaches. A small kernel based on decision procedures type checks (place- 
holder free) terms, and a refiner based on heuristics deals with terms with holes performing 
type inference. Since the kernel is the key component of the system, the one that must be 
trusted, the language is designed to allow the type checking algorithm to be as simple as 
possible. Explicit polymorphism makes type checking CIC terms decidable while allowing 
the same degree of polymorphism as J-""^. These explicit type annotations are usually left im- 
plicit by the user and represent long-distance constraints. In this context unification seems 
to be a necessary device. Moreover, the most characterizing feature of CIC is that types are 
compared taking computation into account, and that types can contain terms, in particular 
functions applications. Thus the kernel is equipped with a quite elaborate machinery to 
compute recursive functions and unfold definitions. Type inference has to provide a similar 
machinery, and possibly extend it to handle types containing metavariables. This extension 
is commonly named higher order unification, and it is a really critical component of an 
interactive prover. Recent important developments [[16] heavily rely on a user-extensible 
unification algorithm [5j, using it as a predictable form of Prolog-like inference engine. In 
other words, unification can be employed to infer terms (content) while type inference is 
employed to infer types and type annotations in the case of explicit polymorphism. For 
these many reasons, we believe that developing type inference on top of unification is a 
sound decision probably necessary to scale to a rich type system like CIC. 

8. Conclusion 

In this paper we studied the design of an effective refinement algorithm for the Calculus of 
(Co) Inductive Constructions. Its effectiveness has been validated in all the formalizations 
carried on using the Matita interactive theorem prover [11^ [H [21 13], whose refiner is based 
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on the algorithm described in this paper. Once again we stress that the refiner component, 
while not being critical for the correctness of the prover, is the user's main interlocutor, and 
is thus critical for the overall user's experience. 

This algorithm is also the result of the complete rewrite the Matita ITP underwent 
in the last couple of years. The refiner algorithm described in this paper amounts to 
approximatively 1600 lines of OCaml code, calling the higher order unification algorithm 
that amounts to a bit less than 1900 lines. To give a term of comparison to the reader, 
the kernel of Matita, written by the same authors, amounts to 1500 lines of data structures 
definitions and basic operations on them, 550 lines of conversion algorithm and 1400 of 
type checking. More than 300 lines of the type checking algorithm are reused by the refiner 
for checking inductive types positivity conditions and recursive or co-recursive functions 
termination or productivity. 

On top of this refinement algorithm all primitive proof commands have been reimple- 
mented. In the old implementation they were not taking full advantage of the refiner, par- 
tially for historical reasons, partially because it was lacking support for placeholder vectors 
and bi-directionality was not always exploited. The size of the code is now 48.9% of what 
it used to be in the former implementation. In particular, it became possible to implement 
many proof commands as simple "notations" for lambda-terms in external syntax. 

A particularity of this work is that the presented algorithm deals with completely raw 
terms, containing untyped placeholders, whose only precondition is to be syntactically well 
formed. In addition it also supports a very general form of coercive sub-typing, where 
inserting the explicit cast may leave uninstantiated metavariables to be later filled by the 
user. This eased the implementation of subset coercions in the style of [20], but that topic 
falls outside the scope of the present paper and is thus not discussed. 

The algorithm could be enhanced adding more rules, capable of propagating more 
typing information. For instance, a specific type forcing rule for /3-redexes (suggested by a 
referee) could be in the form 



enabling the system to propagate the expected type to the abstraction (compare this rule 
with (7^^— letin)). In practice the advantage of this rule is limited, since it is quite infrequent 
for a user to write /3-redexes. A type forcing rule for pattern matching based on the same 
principles, propagating the expected type to the return type of the match, could be of 
greater value, since this construct is more likely to come from the user input. We will 
consider adding such rules in a future implementation. 

The refinement algorithm we presented already validates many desired properties, like 
correctness and termination. Nevertheless we did not even state the relative completeness 
theorem. In a simpler framework, admitting most general unifiers, one could have stated 
that given an oracle for unification, the algorithm outputs a well typed refinement every 
time it is possible and that any other refinement is less general than the produced one. 
Unluckily CIC is higher order and does not admit most general unifiers. To state the 
relative completeness theorem one has to make the oracle aware of the whole refinement 




beta) 



r h [/ ^ U' : s 
Thu: [/' ^ u' 
T;x:U'ht: E[u'/x] U t' 



r h (Ax : U.t) u: E U {\x : U' .t') u' 
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procedure and the oracle has to guess a unifier (or ah of them) such that the remaining 
refinement steps succeed. This makes the theorem way less interesting. Alternatively one 
would have to add backtracking to compensate for errors made by the oracle, and make the 
algorithm distant from the implemented one, that is essentially greedy and backtracking 
free. 

The algorithm presented in the paper is clearly not relatively complete. For ex- 
ample, the rules given in Section [3] do not accept the term / c where c : N and / : 
match ?i in N return Ax. Type [O N | 5 (x : N) =^ N N]. The term is however 
refineable, for instance by instantiating ?i with S O. To obtain a relatively complete al- 
gorithm, we could add additional rules based on the invocation of the unifier on difficult 
problems. For instance, for the example just shown it would be sufficient to unify N — )-?2 
with match ?i in N return Ax. Type [O =^ N | 5" (x : N) N — >• N] for a fresh metavariable 
?2. However, we know in advance that the efficient but incomplete algorithm implemented 
in Matita always fails on such difficult unification problems. The same holds for the similar 
algorithm implemented in Coq. Therefore a relatively complete version of the algorithm 
would remain only of theoretical interest. 

The following weaker theorem, which establishes completeness on well typed terms only, 
can be easily proved by recursion over the proof tree and by inspection of all cases under 
the hypothesis that every pair of convertible terms are unified by the identity metavariable 
instantiation. 

Theorem 8.1 (Completeness for well typed terms). For all well formed S, F and for 
all t and T such that S, <I>, T h t : T we have T h t : T t. □ 

Acknowledgments. We deeply thank Jacques Carette and the anonymous referees for 
their many observations and corrections. 
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Appendix A. Syntax-directed type-checking rules 

The following appendix is an extract of the paper |4| in which the reader can find all the 
details of the type checking algorithm implemented in the Matita interactive prover. A few 
aesthetic changes have been made to the adopted syntax to increase its consistency with 
respect to the syntax adopted in this paper. The main differences are summarised in the 
following list: 

• We use the membership relation over the PTS set to type sorts and products 

• The check for the consistency of the metavariable local substitution has been inlined in 
the rule 

• A new generic judgement (r : T) G Env has been introduced to provide a more compact 
syntax for the lookup of the type of a generic object into the environment 

• We inlined several auxiliary functions that were used in the presentation of the typecheck- 
ing rule for case analysis. 

This was made possible by the following abuse of notation: Env,S,<I>,0 h ti Owhd 
■ T^.tn+i is a shortcut to mean that for all i € {1 . . . n} 
S, T; xi : Ti; . . . ; Xi_i : Ti_i h ti l>whd Ilxj : Tj.tj+i and S, T h tn+i >whd Wi- 

Moreover, the rule presented in jj] is more liberal than the one presented here that just 
uses the test (s, s') G elim(PTS) to check that a non informative data is never analyzed to 
obtain an informative one. The actual rules used in the kernel and the refiner of Matita 
also allow in every situation the elimination of inhabitants of singleton inductive types, 
whose definition is given in [3]. 
In this section, X will be short for 

Hxi : inductive 

II : Ai := kl -.Kl... k"^^ : i^f ^ 
with . . . 

with //^ : An:=ki: K\... A:™" : K"^-- 

A.l. Environment formation rules. Environment formation rules (judgement Env h 
WF, function typecheck_obj) 



h WF 

Env h WF d undefined in Env Env, S h WF Env, E, $ h WF 
Env, S, h T : 5 Env, E, h 5 >„hd S' where S' is a sort 
Env,E,$,0 h 6 : T' Env, E, h T ^ T' 

Env U (E, definition d : T := b) h WF 

Env h WF d undefined in Env Env, E h WF Env, E, $ h WF 
Env, E, h T : 5 Env, E, h 5 >„hd S' where S' is a sort 
Env U (E, axiom d : T) h WF 
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Env h WF undefined in Env Env, S h WF Env, S, $ h WF 
Env, E, h T j : Si Env, S, h Owhd 5"- where 5- is a sort 



Vi ■ Pi Pi + l ^ 

Env, S, CD, [/i : Ti; ...;/„ : r„; h : r';^+i 

_Env, S, ci>, [/i : Ti; ...;/„ : r„; : T^J h T^^+i i T'^^+i 
t„ guarded by destructors ([1], Sect. 6.3) 



i G {1 . . .n} 



Env U 



let rec : r ^j) : rp\+i := ti and . . . | h WF 

\ ^^dfn{x;„--K)--TZ+l ■■=tn 



Env h VFF /„ undefined in Env Env, S h W'F Env, S, ^> h 
Env, S, h Tj : Si Env, S, h o^hd S' where 5' is a sort 



Env, S, CD, [/i : Ti; ...;/„ : r„; h U : r';^+i 

_Env, S, CD, [/i : Ti; ...;/„ : r„; : T^J h T^^^ i T'^^+i 
guarded by constructors ([i]. Sect. 6.3) 



i £ {1. . .n} 



Env U I let core c : T^^J : rp\_^i := ti and . . . | h PFF 

and fn{x^^:T^J : T^^^^ := tn 

EnvhT^F If, /cj,...,/c;f" undefined in Env Env,ShVFF Env,S,$hT^F 

all the conditions in [2], Sect. 6.1 are satisfied 

EnvU ($,E,X) h WF 

A. 2. Metasenv formation rules. Metasenv formation rules (judgement Env, E h WF, 
function typecheck_metasenv) 



Env,0 h WF 

Env, S h WF 7i undefined in S Env, S, 0, T h W^F 
Env, S, 0, r h T : 5 Env, S, 0, T h 5 >„hd 5'where S' is a sort 
Env, S U (r h?i : T) h WF 



44 



A. ASPERTI, W. RICCIOTTI, C. SACERDOTI COEN, AND E. TASSI 



A. 3. Subst formation rules. Subst formation rules (judgement Env, S, $ h WF, function 
typecheck_subst ) 



Env, S, h WF 

Env, S, $ h WF ?i undefined in S and in ^> Env, S, T h WF 
Env, S, r h r : 5 Env, S, T h 5 >„hd S' where S' is a sort 
Env,S,$,r h t : T' Env, S, T h T 4, T' 

Env, S, $ U (r h?i : T := h W^F 



A. 4. Context formation rules. Context formation rules (judgement Env, S, F h WF, 

function typecheck_context) 



Env,S,$,0 h WF 
Env, S, r h WF X is undefined in F 

Env, S, r h T : 5 Env, S, T h 5 l>whd S' where S" is a sort 

Env, S, r U (x : T) h VFF 
Env, S, $, r h PTF a; is undefined in T 

Env, S, r h T : 6* Env, S, T h S* Owhd <S" where S" is a sort 
Env, S, r h t : T' Env, S, ^>, T h T i T' 

Env, S, r U (x : T := t) h W^F 



A. 5. Term typechecking rules. Term typechecking rules (judgement Env, S, F h t : T, 

function typeof) 

(/C-variable) ■=„.. /r. 1 (/C-sort) 



Env,S,$,r h X : T ' ' Env, S, T h si : S2 

(xi : Ti; . . . ; a;„ : T„ 1 -?^ : T) £ S or (xi : Ti; . . . ; x„ : r„ : T := i) G $ 

Env,S,$,rhti :ri[xi_i/ti_;] iG{l...n} 
(/C— metaj 



Env,S,$,rh?4ti;...;t„] : T[x„/t„] 
(r : T) G Env 



(/C— constant) 



Env,E,$,r h r : T 



(S', definition d : T := b) & Env or (S', axiom d : T) e Env 
S' = = 

(/C-definition) (rf : T) G Env 
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let rec ■ f pi) ■ ^A+l "= *l 



(/C— letrec) 



S' = $' = l<i<n 



G Env 



(/C— letcorec) 



let corec^/i(x^ : T^^) : T^^.^.^^ := ti and 

\ and fn{Xp^ ■'^p„) ■ •= 
$' = l<i<n 



e Env 



(A^— inductive) 



(/i : Ti) G Env 

(E',$',X) G Env 

S' = $' = l<p<n 

{If : U^^i.Ap) e Env 



(/C— constructor) 



(/C— lambda) 



(/C— product) 



(/C— letin) 



(/C— appl — base) 



(/C— appl — rec) 



(S',^>',X) G Env 

S' = $' = l<p<n l<j<mp 
(4 : nxi : C//.i^^) G Env 
Env,S,^>,r h T : S 

Env, S, r h S i>whd -S" 5" is a sort or a meta 
Env,S,$,ru (n : T) \- u : U 

Env, S, r h An : T.u : Un : T.U 

Env,S,$,r h T : si 
Env,E,$,ru (n : T) \- U : S2 

{S1,S2,S3) G PTS 

Env,S,$,r I- Un : T.U : S3 
Env,S,$,ri-i :r' 

Env,S,$,rhr: S Env, S, T h T | T' 
Env, S, r U (x : T := t) h u : [/ 

Env, E, r h let (x : T) := i in ■u : U[x/t] 

Env,E,^>,r h h:Ux: T.U 
Env,S,$,r h t : r' Env, S, T h T i T' 



Eny,l],^,T\-ht:U[x/t] 
Env, S, r h (/t ti)t2---tn:T 
Env, S, r h /i t2---tn:T 
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G Env S' = = Env, S, T h t : T 
Env,S,«>,rhr>„M/f 4^ ^ 

= ^Ur '■ yl-s kI\xi/ui] = Uxi. : Q j. .If • j; vt j = l---mp 
Env, S, r h [/ : y Env, S, T h y l>„hd Hz^ : K.nz^+i : If 4 ^-s' 
(s,s') e elim(P TS) 

Env, S, r h Ax^ : Pl,-tj : T j _^ j = 1, . . . , mp 

Env,S,^>,rhrjinx^n. :g4.^^ (fcf ^x(^) i = l,...,mp 

(/C— match) ^ = ^ 

Env, S, r h match t in /, return U 

~J Y rn^ ~^ 



A. 6. Term conversion rules. Term conversion rules (judgement Env,S,<^,r h T ^ T', 
function are_convertible ; ^= means test_eq_only — true; 4, means that the current rule must 
be intended as two rules, one with all the |, replaced by |, the other with all the |, replaced 
byi=) 

Env,S,$,r h T =a T' 
Env,S,$,rhri= T' 
Env,S,$,rhri= T' 
Env,S,$,rh TIT' 

Type„ < Type^ Type„ < Type„ are declared constraints ([1], Sect. 4.3) 
Env, S, r h Type„ i= Type^ 

Type„ < Type^ is a declared constraint ([Ij, Sect. 4.3) 
Env,S,$,rhType„iType„ 

Env, E, $, r h Prop | Type„ 

for alH = 1, . . . , n Env, E, T h ti |, t ■ 
Env,S,$,r h?j[/c] i.?j[/c'] 
Env, S, r h Ti 1= T{ Env, E, T U (x : Ti) h Ta U 
Env, E, r h nx : Ti.Ta U : T{.T^ 
Env,E,$,ru (x : T) h 1 1, t' 

Env, E, r h Ax : T.t i. Ax : T'.t' 

In the rule above, no check is performed on the source of the abstractions, since we assume 
we are comparing well-typed terms whose types are convertible. 

Env,E,$,rh /li, h' 

for alH = 1, . . . , n Env, E, T h U |= t- 
Env,E,^>,r h httUh'Ki 
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Env, S, r h U. i' Env, S, r h ?7 I, [/' 

for alH = 1, ■ ■ ■ , mp Env, S, T h \x\^ : pj .tj U A< : P'j^ A 

Env, S, ^, r h match t in Jf return U \k{ ( <T^\ ^ ti| . . . (x ^:, : Pnl^) ^ t^,\ U 
match t' in /f return U [kl (<Tp^) ^ t^l . • • |C, (C^ : ^7^) ^ CJ 

Env,S,$,ri-ii>whdi' Env, S, T h n >whd Env, S, T h |, u' 

Env,S,$,r H 1 1, u 

In the previous rule, t' and ti' need not be weak head normal forms: any term obtained 
from t (respectively, u) by reduction (even non-head reduction) will do. Indeed, the less 
reduction is performed, the more efficient the conversion test usually is. 



A. 7. Term reduction rules. Term reduction rules. 

Env,i;,$,r h (Ax : r.u) i u[x/t\ 

Env, S, r h let {x : T) := t in u u[x/t] 

(0, 0, definition d : T := b) e Env 
Env,S,^>,rhd >s b 
(r' h?i : T := t) G $ 



Env,S,$,r h?j[Mi ; . . . ; Un] >s t[domir)/K] 



Env, S, r h match kf U t'^. in If return U 



IK i< : Pn\) ^ ^il • • • IC, (C4 : PrjJ ^ Um,] 

/0,0, ^ \ 

let rec /i(xi^ : T^J : rp\+i := and . . . G Env 
ke{l...n} 

Env, S, r h /fe ui ...(/cj i};;^)... u„i D>^ tk[x'^/ui,...,{kju;^.),...,Um] 

Notice that (kj v^.) must occur in the position of the recursive argument of fk- This 
implies that, for this reduction to be performed, fk must be applied at least up to its 
recursive argument. 
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let corec /i(x^: T^J : T^,^^^ := ti and 



G Env 



k e {1.. .n} 



Env, S, <I>, r h match Uq in if return U 



match tfc[2^/M^] in /J' return [/ 

[A:? ^ ^ll ■ ■ ■ IC, (yn4 :Pr4) 

Notice that here q can be zero. 



v„ 
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